‫Jonas: Vamos agora continuar escrevendo nossa
‫função de proteção de middleware.
‫Portanto, na última aula, lemos o
‫token do cabeçalho de autorização
‫e depois verificamos se o token realmente existe.
‫Bem aqui.
‫E a seguir, temos a etapa de verificação do token.
‫E espero que você lembre
‫que nesta etapa, verificamos se alguém manipulou
‫os dados ou também se o token já expirou.
‫Então, já usamos, do pacote de tokens da Web JSON, a função de
‫função de atribuição,
‫e agora vamos usar a função de verificação.
‫Assim como antes, jwt. verifique, e aí,
‫como você pode imaginar, passamos o token para que o algoritmo
‫possa ler a carga útil e, em seguida,
‫lembre-se de que essa etapa também precisa do segredo.
‫Então, basicamente, a fim de criar a assinatura de teste.
‫Então, esse segredo é o processo. env. JWT_SECRET.
‫Lembre-se disso?
‫Agora, como um terceiro
‫argumento, essa função realmente requer uma função de retorno de chamada.
‫Portanto, esse retorno de chamada
‫será executado assim que a verificação for concluída.
‫Então você vê que esta
‫verificação aqui é na verdade uma função assíncrona.
‫Assim, ele verificará um token e, depois disso,
‫quando terminar,
‫chamará a função de retorno de chamada que podemos especificar.
‫Bem, trabalhamos com promessas o tempo
‫todo e não quero quebrar esse padrão aqui.
‫E assim, vamos realmente prometendo essa função.
‫Então, basicamente, para fazer com que ele retorne uma promessa.
‫E, dessa forma, podemos usar async
‫await como qualquer outra função assíncrona que estamos usando.
‫Portanto, para fazer
‫isso, o Node realmente tem uma função promisify integrada.
‫Tudo o que precisamos fazer para
‫usá-lo é exigir o módulo utilitário integrado.
‫Então, vamos fazer isso no topo, na verdade.
‫Então isso vai criar um objeto chamado util, require ...
‫Tudo bem, então isso significa utilidade.
‫Não era isso que eu queria.
‫Então isso significa utilidade.
‫E então vamos usar o método promisify.
‫Mas, uma vez que usaremos apenas esse método, podemos realmente
‫fazer isso com mais facilidade.
‫Portanto, em vez
‫de fazer isso, podemos simplesmente desestruturar esse objeto e receber
‫a promessa diretamente a partir daí.
‫Então, novamente, isso é apenas usar a desestruturação ES6.
‫Ok, agora é muito fácil de usar.
‫Tudo o que temos a fazer é chamar promisify.
‫Portanto, prometam e, em seguida, passem a função lá.
‫E agora, tudo isso aqui é uma
‫função que
‫precisamos chamar, que retornará uma promessa.
‫Então aqui, nós realmente chamamos a função.
‫E isso irá retornar uma
‫promessa, então podemos aguardar e armazenar o resultado em uma variável.
‫Portanto, o valor do resultado da promessa
‫será, na verdade, os dados
‫decodificados, ou seja, a carga útil decodificada desse token da Web JSON.
‫Deixe-me chamá-lo de decodificado aqui.
‫Tudo bem.
‫E podemos esperar, porque na verdade já dissemos que
‫é uma função assíncrona.
‫E agora, só para ver se realmente
‫funciona, vamos registrar esses dados decodificados no console também.
‫E, na verdade, podemos remover este console. faça logoff do token.
‫Aquele de que não precisamos mais.
‫Então, vamos tentar enviar essa solicitação novamente, sim, mas desta
‫vez ativando esse cabeçalho de autorização
‫para enviarmos um token da Web JSON junto com a solicitação.
‫Então foi isso que enviou.
‫E agora, de fato, temos acesso
‫aos dados e, portanto, agora temos acesso à rota protegida.
‫OK?
‫Mas o que eu queria ver é esse objeto decodificado aqui.
‫E então este aqui deve ser o ID do usuário.
‫Então, vamos dar uma olhada nisso no Postman novamente.
‫Portanto, 62a42.
‫E então, de fato, bem, onde temos isso?
‫Vamos dar uma olhada no Compass.
‫E, de fato, o ID desse usuário é 62a42.
‫E isso significa que realmente temos
‫nossa carga útil correta aqui.
‫Então, basicamente, o ID de usuário correto.
‫Então, também temos o carimbo de data / hora da
‫data de criação e da data de expiração do token.
‫Então está funcionando.
‫Mas agora vamos realmente tentar manipular a carga útil
‫desse token.
‫Então, vamos copiá-lo aqui novamente.
‫Mas então vou para o depurador JWT.
‫Então, novamente, em jwt. Io.
‫Então, vamos tirar isso.
‫E agora o que vou fazer é alterar alguns
‫dados aqui e isso mudará o token codificado aqui, que posso
‫seguir em frente e copiar.
‫Então, vamos simplesmente substituir, na
‫verdade, vou apenas substituir esses dois números aqui
‫por algo diferente.
‫E então, como você pode ver, isso mudou o token aqui.
‫E agora, tentarei obter acesso a
‫essa rota protegida
‫usando este token da Web JSON manipulado.
‫Ok, faz sentido?
‫Então, só para ver se está funcionando corretamente.
‫Então, estou copiando
‫este aqui agora e colando este outro diferente.
‫E então, se eu enviar esta solicitação, obteremos um erro.
‫Tão bom.
‫Portanto, vemos que o nome do erro é
‫JsonWebTokenError e temos uma assinatura inválida.
‫Tão bom.
‫Isso é exatamente o que estávamos procurando.
‫Portanto, esse é um dos dois erros que podem ocorrer.
‫O outro é que o token já expirou.
‫Este é chamado JsonWebTokenError e, na
‫verdade, vamos prosseguir e lidar com esse erro agora.
‫E a maneira
‫que poderíamos fazer é adicionar um bloco try-catch bem aqui.
‫Direito?
‫Logo depois de fazer esse código,
‫poderíamos introduzir um bloco
‫try e, em seguida, no catch, criaríamos erros
‫que seriam enviados ao cliente.
‫Agora, em vez de fazer
‫dessa forma, eu realmente quero usar nosso middleware de tratamento
‫de erros global para fazer isso por nós.
‫Portanto, não gostamos de lidar com erros aqui mesmo em
‫nossa função de middleware.
‫Em vez disso, geralmente o delegamos ao controlador de erro.
‫E então, vamos fazer exatamente a mesma coisa aqui.
‫Então controlador de erro.
‫E então é exatamente a mesma
‫coisa que temos com nossos outros erros aqui.
‫Por exemplo, o erro de validação vindo do Mongoose,
‫então de outra biblioteca.
‫E agora, esse erro está realmente vindo de outra
‫biblioteca e também tem seu próprio nome.
‫Então vamos ver isso.
‫E é JsonWebTokenError.
‫Tudo bem.
‫E então, vamos fazer muito semelhante aqui.
‫Então se. nome é
‫este, então o erro deve ser igual a manipular o erro.
‫OK.
‫Portanto, vamos prosseguir
‫e criar esta função, na verdade, em algum lugar aqui.
‫E este é extremamente simples.
‫Tudo o que ele faz é pegar um
‫erro e retornar um novo AppError.
‫OK?
‫Portanto, nesta
‫função de seta ES6, como espero que você saiba, podemos escrever essas
‫linhas simples onde não precisamos
‫nem especificar as chaves e nem a palavra-chave return.
‫Portanto, isso retornará automática
‫e implicitamente tudo o que colocarmos aqui.
‫Direito?
‫E
‫então, o que queremos dizer aqui é simplesmente, token
‫inválido, faça login novamente.
‫E então, o código de erro, como antes,
‫é um 401 para não autorizado.
‫Agora, isso só funciona, lembre-se, na produção.
‫E então, se fizéssemos isso agora de novo,
‫obteríamos exatamente a mesma coisa.
‫E então, vamos voltar aqui e
‫executar isso na produção.
‫Então npm run start: production.
‫Sim, assim mesmo.
‫Portanto, se tentarmos
‫novamente, vamos ver se obtemos nosso erro.
‫E, de fato, nós fazemos.
‫Portanto, se, agora, um usuário em produção
‫tentar acessar nosso aplicativo com um
‫token inválido, bem, ele receberá apenas esta mensagem de erro.
‫Tudo bem?
‫Portanto, esse é o primeiro erro que podemos obter.
‫Mas outra é que o usuário tenta
‫acessar o aplicativo
‫com um token já expirado.
‫E então, agora vamos tentar criar esse erro.
‫E para fazer isso, alterarei
‫o tempo que leva para o token expirar.
‫Portanto, agora, temos 90 dias.
‫Vamos colocar em, tipo, cinco segundos.
‫OK.
‫Dê uma chance.
‫E agora tente fazer o login novamente.
‫Então, vamos salvar este aqui também.
‫Então, entre em usuários e, em seguida, faça login.
‫Assim, podemos fazer login e isso nos dará um novo token,
‫mas esse token só é válido por cinco segundos.
‫E então, esses cinco segundos deveriam ter passado neste ponto.
‫Portanto, agora copiarei esse token e tentarei acessar nossa
‫rota protegida usando esse token.
‫Então cole aqui.
‫E agora, vamos ver o que temos.
‫E, na verdade, por algum motivo, funcionou.
‫Então, vamos dar uma olhada em nosso depurador JWT novamente.
‫E diz, criado em 2 de maio, mas expira
‫apenas em 31 de julho.
‫Então, algo deu errado na criação do token, eu acho.
‫E então, vamos mudar isso aqui novamente.
‫E vou colocar cinco aqui.
‫E então, esse cinco deve
‫representar cinco milissegundos, ou posso até, tipo, colocar
‫5000, que deve ser cinco segundos.
‫OK.
‫Deixe-me salvá-lo novamente para reiniciar o servidor.
‫Tente de novo.
‫Então, faça login novamente aqui.
‫Tudo bem.
‫Agora, tudo o
‫que precisamos fazer é basicamente esperar cinco segundos, e esse tempo já deve ter passado neste ponto.
‫Cole aqui novamente.
‫E vamos lá.
‫E, de fato, obtemos um erro.
‫Agora lembre-se de
‫que esse é basicamente o erro padrão que
‫obtemos caso não o tratemos corretamente.
‫Direito?
‫Então, vamos dar uma olhada no erro.
‫E, na verdade, temos aqui no console.
‫Então, vamos ver de onde vem isso.
‫E sim, vem deste lugar.
‫Portanto, este é o caso em que temos um erro desconhecido.
‫Lembre-se, portanto, um erro que não está marcado
‫como um erro operacional e,
‫portanto, queremos registrá-lo.
‫Então, nós registramos aqui e enviamos
‫essa mensagem de erro
‫genérica para o cliente, aquela que acabamos de
‫ver no Postman.
‫Mas aqui temos os detalhes desse erro.
‫E então, este tem o nome de TokenExpiredError.
‫Tudo bem.
‫E então, agora vamos lidar com isso também.
‫Portanto, estou copiando agora e, em seguida, crio apenas
‫outro se estiver aqui.
‫Portanto, se o erro. nome é igual a este, bem,
‫digamos, manipule JWTExpiredError
‫com
‫a seta.
‫Vamos copiá-lo e colocá-lo bem aqui.
‫E isso, é claro, é muito semelhante ao anterior.
‫Seu token expirou.
‫Por favor faça login novamente.
‫E novamente, com um código de erro 401.
‫Ok, vamos tentar de novo.
‫E então, essa é exatamente a mensagem de
‫erro que devemos ver agora aqui.
‫Tudo bem.
‫E realmente é.
‫Excelente.
‫Vamos terminar o processo
‫aqui e iniciá-lo no modo dev, é claro.
‫Então npm
‫start, e tudo bem.
‫Então, este, não precisamos mais, então vamos fechá-lo.
‫Ou, na verdade, vamos corrigir esse pequeno erro aqui, porque, na verdade, não
‫usamos esse erro aqui de forma alguma.
‫Então, vamos nos livrar disso.
‫E então aqui embaixo, não precisamos passar lá.
‫Legal.
‫É claro que também precisamos mudar isso de volta para 90 dias.
‫Tudo bem.
‫E
‫então, só para ter certeza, vamos fazer login aqui
‫novamente, copiar o
‫token e colocá-lo aqui.
‫Agora, este processo de copiar o token
‫e depois colá-lo aqui neste cabeçalho pode parecer
‫um pouco estranho e, na verdade, vamos consertar
‫isso em um
‫dos vídeos futuros para que
‫basicamente esse processo aconteça automaticamente.
‫Mas agora, o que é importante é que
‫ele voltou a funcionar.
‫Portanto, podemos realmente nos livrar deste console. faça login aqui e vá para
‫a próxima etapa.
‫E poderíamos realmente parar aqui agora, se quiséssemos.
‫E, novamente, a maioria dos tutoriais que você
‫vai descobrir por aí, na verdade, apenas param por aqui.
‫Mas isso ainda não é seguro o suficiente.
‫Então, por exemplo, e se o usuário tiver
‫sido excluído nesse meio tempo?
‫Portanto, o token ainda existirá, mas se
‫o usuário não existir mais,
‫bem, então não queremos logá-lo, certo?
‫Ou pior ainda, e se o usuário realmente alterou
‫sua senha depois que o
‫token foi emitido?
‫Bem, isso também não deve funcionar, certo?
‫Por exemplo, imagine que alguém
‫roubou o token JSON da web de um usuário.
‫Mas então, para
‫se proteger contra isso, o usuário muda sua senha.
‫E então, é claro, aquele token antigo emitido
‫antes da alteração da senha não deve mais ser válido.
‫Portanto, não deve ser aceito o acesso a rotas protegidas.
‫E então, esse é o tipo de coisa que vamos implementar aqui
‫na etapa três e na etapa quatro.
‫Portanto, a primeira coisa a fazer é verificar se o
‫usuário realmente ainda existe.
‫E então, esse deve ser o mais fácil.
‫Então, digamos apenas, usuário. findById.
‫E então, agora é por isso que
‫realmente temos o ID na
‫carga útil, porque agora podemos usar esse ID
‫e consultar o usuário usando apenas esse ID.
‫Tão decodificado. identificação.
‫Tudo bem?
‫Então, isso deve localizar o novo usuário.
‫E, claro, precisamos aguardar isso e, em
‫seguida, armazená-lo em uma variável.
‫Estou chamando de FreshUser.
‫Tudo bem?
‫Porque não é realmente um novo usuário.
‫É só quando criamos um.
‫Mas este não é realmente um novo, é apenas
‫o usuário com base no ID decodificado.
‫OK?
‫E podemos
‫fazer isso para ter 100% de certeza de que o
‫ID está realmente correto, porque se fizemos
‫isso até este ponto do código aqui, isso significa que o processo
‫de verificação que temos anteriormente, aqui, foi bem-sucedido.
‫Caso contrário, isso causaria um erro
‫que impediria a função
‫de continuar.
‫E então, novamente, este
‫processo de verificação aqui é responsável por verificar
‫se ninguém alterou a ID
‫que está na carga deste token.
‫E então, por causa disso,
‫podemos ter 100% de certeza de que o usuário para
‫o qual emitimos o JWT é exatamente aquele cujo ID está
‫agora dentro da carga decodificada, então este.
‫OK?
‫Portanto, o processo de verificação é realmente fundamental.
‫É realmente o que faz todo esse trabalho.
‫De qualquer forma, agora o que precisamos fazer é
‫verificar se realmente existe um novo usuário.
‫E se não, bem então, é claro, vamos
‫retornar um novo erro.
‫Portanto, se não houver nenhum
‫freshUser, retorne deste middleware e chame o
‫próximo com um erro.
‫Portanto, este é um padrão
‫que temos visto continuamente neste ponto, certo?
‫Portanto, o token não existe
‫mais.
‫E, na verdade, é o contrário.
‫Portanto, na verdade, o
‫usuário pertencente ao token não existe mais.
‫Direito?
‫E então, o 401.
‫OK.
‫Então, vamos testar isso mais uma vez.
‫E vamos criar um novo usuário para isso.
‫Portanto, apenas teste com a mesma senha para que estejamos sempre
‫usando a mesma aqui apenas para tornar o
‫nosso teste um pouco mais fácil.
‫E eu sei que todos esses testes aqui
‫fazem o vídeo levar muito tempo,
‫mas é claro, é muito importante que testemos tudo o que
‫fazemos, especialmente em
‫um tópico tão importante como autenticação.
‫Agora estou usando este JWT aqui, estou
‫colando aqui, mas é claro, antes de enviar a solicitação,
‫irei excluir esse usuário imediatamente.
‫OK?
‫Então, novamente, vamos fingir
‫que alguém criou um usuário e se conectou, e
‫digamos que, depois de algum tempo, o usuário foi excluído.
‫Mas, nesse ínterim, alguém poderia ter obtido acesso a esse
‫JWT
‫e agora poderia tentar fazer login como aquele
‫usuário que, de fato, já foi excluído.
‫E então, novamente, não devemos deixar isso acontecer.
‫Então, deixe-me deletar este usuário aqui agora.
‫E lá vamos nós.
‫E então, vamos testar agora.
‫E, novamente, lembre-se de que o
‫usuário pertencente ao ID que está nesta carga útil não está mais lá.
‫Então vamos ver.
‫E, de fato, recebemos essa mensagem de erro que acabamos de criar.
‫Então esse também está funcionando.
‫E vamos para o último.
‫Portanto, etapa número quatro, verifique se o usuário
‫alterou sua senha recentemente.
‫Então, basicamente, depois que o token foi emitido.
‫E para implementar esse teste, criaremos outro
‫método de instância.
‫Basicamente, um método que
‫estará disponível em todos os documentos.
‫Portanto, os documentos são instâncias de um modelo.
‫Tudo bem?
‫E fazemos isso porque
‫é uma grande quantidade de código que precisamos para esta verificação.
‫E então, na verdade, esse
‫código pertence ao modelo de usuário e não realmente ao controlador.
‫OK?
‫E então, vamos
‫fazer isso exatamente como fizemos antes para verificar a senha.
‫Portanto, no modelo de usuário, já
‫implementamos este método de instância estática correctPassword, lembra?
‫E então, vamos agora criar outro.
‫Então userSchema. métodos. changesPasswordAfter.
‫Então funcione, e para esta função,
‫passaremos o carimbo de data / hora JWT.
‫Então, basicamente, o carimbo de data / hora que
‫diz quando o token foi emitido.
‫Então, vamos chamá-lo de JWTTimestamp.
‫Tudo bem.
‫E, por padrão, retornaremos false deste método.
‫E isso significa que o usuário não alterou
‫sua senha
‫depois que o token foi emitido.
‫OK?
‫Então vamos colocar isso aqui, return false, basicamente por padrão.
‫OK.
‫Mas então,
‫também temos if this, e lembre-se que em um método de instância,
‫a palavra-chave this sempre aponta para o documento atual.
‫E portanto, aqui temos acesso às propriedades.
‫Agora, na verdade, precisamos criar um campo agora em nosso esquema
‫para a data em que a senha foi alterada.
‫Então, ainda não temos isso.
‫Então, vamos adicioná-lo rapidamente aqui.
‫Portanto, passwordChangedAt e o tipo dela
‫será uma data.
‫Agora, essa propriedade passwordChangedAt aqui sempre
‫será alterada, é claro, quando alguém
‫alterar a senha.
‫Então, no momento, não temos essa lógica em nenhum lugar, e
‫em nenhum lugar estamos realmente definindo essa propriedade.
‫E assim, a maioria dos documentos, a
‫maioria dos usuários, eles simplesmente não terão essa propriedade
‫em seus dados, então em seu objeto, certo?
‫E então, é claro, precisamos testar isso.
‫OK?
‫Portanto, se a
‫propriedade passwordChangedAt existir, só então queremos realmente fazer a comparação.
‫OK?
‫Mas se
‫não, se passwordChanged não existir, então isso significa que o usuário
‫nunca alterou a senha de
‫fato e, portanto, podemos simplesmente retornar false.
‫Então, novamente, esse é o nosso padrão, o que significa
‫que o usuário não alterou a
‫senha após esse carimbo de data / hora.
‫OK.
‫E
‫agora, apenas para começar, vamos realmente registrar isso no console. passwordChangedAt e, claro, o JWTTimestamp também, só
‫para
‫vermos como poderíamos compará-los.
‫Tudo bem.
‫E agora precisamos
‫criar um usuário que tenha essa propriedade, certo?
‫E novamente, mais tarde na seção, quando
‫implementaremos a lógica
‫para alterar a senha, definiremos essa propriedade.
‫OK?
‫Mas agora
‫iremos, basicamente, configurá-lo artificialmente aqui quando criarmos um novo usuário.
‫OK?
‫Então, vamos colocar isso aqui.
‫E aqui, qualquer data, na verdade, servirá.
‫Digamos 30 de abril de 2019 aqui.
‫E então isso deve ser analisado no MongoDB muito bem.
‫Vamos tentar, ver se funciona.
‫E isso não funcionou.
‫Portanto, não foi possível analisar realmente a data, digamos.
‫E, na verdade, preciso começar com o ano e
‫depois com o dia no final.
‫Então, 2019 e depois 30 de abril.
‫Tente de novo.
‫E então você vê que agora está realmente funcionando.
‫Portanto, temos essa data analisada aqui.
‫OK?
‫Agora, para realmente ver
‫o resultado disso, é claro que precisamos chamar esse método.
‫OK?
‫Então é isso que faremos aqui na etapa quatro.
‫OK?
‫E então, lembre-se
‫de que podemos chamar esse método de instância em um documento do usuário.
‫Então, FreshUser. alteradoPasswordAfter e, em seguida, esse carimbo
‫de data / hora.
‫Então isso é decodificado. iat, então emitido em, basicamente.
‫Tudo bem.
‫Então, vamos simplesmente ver o resultado disso.
‫E então, é claro, isso deve agora,
‫não aqui, então deve registrar no console esses dois valores.
‫OK.
‫Agora, é
‫claro que preciso fazer login exatamente com esse usuário, então com o
‫teste, então vamos lá.
‫Conecte-se.
‫Copie este token aqui novamente.
‫E, novamente, vamos basicamente automatizar
‫isso no próximo vídeo, na verdade.
‫OK.
‫Cole aqui.
‫E agora, temos esse bug aqui.
‫Então, eu apenas digitei errado o nome da função aqui.
‫Bem, vamos apenas copiar.
‫Tente de novo.
‫Oh cara.
‫O que há de errado agora?
‫E vejo que simplesmente esqueci este registro aqui.
‫Então, outro erro estúpido.
‫Provavelmente viu aquele chegando.
‫Mas agora vamos lá.
‫Então, tudo funcionou
‫bem, e tudo o que
‫realmente queríamos ver agora são esses dois resultados.
‫Basicamente, temos este aqui neste formato de data
‫e, em seguida, o outro neste milissegundo ou segundo carimbo de data /
‫hora aqui.
‫E então, agora precisamos converter este passwordChangedAt também
‫em um carimbo de data / hora como esse.
‫Tudo bem?
‫E então, para isso, vamos criar uma nova variável.
‫Tão alterado Timestamp.
‫E podemos usar isso. passwordChangedAt. consiga tempo.
‫OK?
‫E então,
‫essa é uma das muitas funções de data que o JavaScript nos oferece.
‫Tudo bem.
‫E agora, vamos comparar rapidamente
‫esses dois porque não estamos totalmente prontos ainda, na verdade.
‫Então mandando só pra ver os resultados aqui.
‫E então o que vemos aqui basicamente é que
‫este aqui está
‫agora, basicamente, em segundos, e este em milissegundos.
‫Portanto, é 1000 vezes mais.
‫E assim, sabemos que precisamos dividir isso por
‫1000 e, em seguida, analisar tudo isso como um número inteiro.
‫E para isso, usamos parseInt.
‫Portanto, outra função JavaScript está disponível para números.
‫E então também precisamos especificar a base.
‫Portanto, este é um número de base 10.
‫Tudo bem?
‫E agora, vamos, na verdade, novamente, ver o resultado.
‫E agora, isso parece muito mais amigável.
‫OK.
‫E então, agora vamos retornar nosso resultado.
‫E, novamente, lembre-se de que falso significa não alterado.
‫OK?
‫E não alterado
‫significa basicamente que o dia ou a hora em que o token foi emitido é menor que
‫o carimbo de data / hora alterado.
‫OK?
‫Portanto, apenas como exemplo
‫aqui, digamos que o token foi emitido no momento 100.
‫Mas então, mudamos a senha, digamos, no tempo 200.
‫OK?
‫E assim,
‫mudamos a senha depois que o
‫token foi emitido e, portanto, isso agora é verdade.
‫Tudo bem?
‫E é exatamente isso que queremos retornar
‫aqui, porque falso significa que
‫não mudou e, portanto, verdadeiro, é claro, significa alterado.
‫E então, é exatamente isso que temos aqui.
‫Mas agora, digamos que a senha foi
‫alterada pela última
‫vez em 200, mas só depois
‫disso, emitimos o token, digamos, no momento 300.
‫E então, 300, menos de 200?
‫Não, isso é falso.
‫E então, retornamos falso, o que novamente significa não alterado.
‫E é por isso que usamos este sinal de menos aqui.
‫OK?
‫Vamos voltar ao nosso controlador e realmente usá-lo.
‫Portanto, se a senha foi realmente alterada,
‫bem, neste caso, queremos um erro.
‫Então, volte em seguida, novamente, um novo AppError.
‫Recentemente...
‫Por favor faça login novamente.
‫OK.
‫E mais uma vez, código 401.
‫Tudo bem.
‫Portanto, novamente, isso
‫retornará verdadeiro se o usuário realmente alterar sua senha.
‫E então, se tudo isso aqui for
‫verdade, bem, então exatamente nesse caso é quando
‫queremos que esse erro aconteça.
‫Tudo bem?
‫Então essa foi a última etapa.
‫OK.
‫Então, basicamente, se o código pode chegar
‫ao final deste código aqui, só então, o próximo será executado.
‫E então, com next, vamos para o próximo manipulador
‫de rota, o que efetivamente significa conceder acesso
‫a essa rota protegida.
‫Vamos realmente colocar isso aqui.
‫Conceda acesso à rota protegida.
‫OK?
‫Porque isso é realmente tudo o que o próximo faz.
‫Em seguida, nos leva ao próximo
‫middleware, que normalmente é, então, o próprio manipulador de rotas, ou
‫seja, aquele que envia de volta os dados que estavam protegidos.
‫OK.
‫A última coisa
‫que queremos fazer aqui é colocar todos os dados do usuário na solicitação.
‫Portanto, podemos simplesmente dizer req, então solicite,. o usuário será igual ao
‫freshUser.
‫OK.
‫E de novo,
‫é claro, o código
‫só chega a esse ponto aqui caso tudo esteja correto.
‫OK?
‫E então, isso
‫aqui pode ser útil em algum momento no futuro.
‫Excelente.
‫Vamos testar isso mais uma vez.
‫E, basicamente, essa mudança está no passado agora.
‫E então, esse token que temos aqui, ou na verdade, eu
‫poderia ter reutilizado
‫apenas este em vez de registrá-lo novamente.
‫Mas de qualquer maneira, este
‫token foi emitido após a alteração da senha.
‫E então, este token agora deve funcionar.
‫Então, vamos realmente fazer login
‫novamente e tentar com este token.
‫E, de fato, temos acesso.
‫Agora, indo para o Compass para alterar essa data.
‫OK.
‫Vamos colocar um mês depois.
‫E então, isso será no
‫futuro, pelo menos, no meu futuro quando eu estiver gravando este vídeo.
‫Claro, você fará isso mais tarde.
‫E então, para testar isso, por favor, coloque isso em seu futuro.
‫Então, no futuro da data em que você está
‫assistindo este vídeo.
‫Portanto, se eu
‫voltar ao Postman e efetuar login novamente, ok, se eu efetuar login
‫novamente agora e tentar acessar essa
‫rota, bem, este token será
‫emitido, basicamente, após a alteração da senha.
‫Ou, na verdade, antes que a senha seja alterada.
‫Então, desculpe por essa confusão.
‫Portanto, a senha foi alterada em 30 de
‫maio, mas este token foi emitido em 2 de maio, e assim, antes.
‫Então, basicamente, agora é como se o usuário tivesse alterado sua senha
‫depois que o token foi emitido.
‫E então, essa é exatamente a situação em que não queremos dar
‫acesso à rota protegida.
‫E então, isso agora deve refletir isso.
‫E, de fato, o usuário alterou a
‫senha recentemente, faça o login novamente.
‫Excelente.
‫Então agora funciona.
‫Portanto, nosso middleware de proteção agora está completamente implementado.
‫Vamos nos livrar deste console. faça login aqui.
‫Não preciso mais disso.
‫E tudo bem.
‫Então, vamos recapitular rapidamente, e este
‫vídeo está demorando muito,
‫um pouco mais do que eu esperava.
‫Mas é muito
‫importante entender e explicar como tudo
‫isso funciona e por que é importante.
‫E então, eu prefiro isso do que fazer este vídeo muito mais curto.
‫Claro, eu poderia simplesmente escrever o código, mas você não entenderia realmente o
‫que está acontecendo.
‫Então essa parte a gente já entendeu.
‫Então, essa parte, também acredito,
‫então é aqui que a verificação acontece,
‫basicamente ver se a carga útil do
‫token não foi manipulada por algum terceiro malicioso.
‫OK?
‫E como chegamos
‫a esse código aqui, isso significa que ninguém
‫alterou o token da web JSON e, portanto, podemos obter um novo usuário.
‫Então, basicamente, podemos obter o usuário
‫atual, vamos chamá-lo de currentUser.
‫Por que não?
‫Então, aqui, aqui e também aqui.
‫OK?
‫Portanto, podemos obter
‫o currentUser desse ID que acabou de ser decodificado da carga útil.
‫Agora, se o currentUser não existe,
‫então é para isso que estamos testando
‫aqui, bem, então, nesse caso, não queremos dar
‫acesso à rota
‫e, em vez disso, criar este novo erro.
‫Mas se o usuário existe, então
‫vamos para o
‫ponto número quatro, onde verificamos se uma mudança de
‫senha aconteceu depois que o token foi emitido, certo?
‫E se assim foi, então, novamente, criamos um novo erro.
‫E se não funcionou, então vamos até
‫o final da
‫função de middleware, onde
‫atribuímos o currentUser para solicitar. usuário para que possamos usá-lo em
‫uma próxima função de middleware.
‫OK?
‫Porque lembre-se,
‫esse objeto de solicitação, é aquele que viaja,
‫basicamente, do middleware para o middleware.
‫E então, se quisermos passar dados
‫de um middleware para o
‫próximo, podemos simplesmente colocar algumas coisas no objeto
‫de solicitação, e então esses dados estarão disponíveis em um ponto posterior.
‫Tudo bem.
‫Então é isso.
‫Este é
‫um algoritmo de proteção de rota
‫muito sofisticado e muito completo, basicamente, mas acho que é realmente importante fazê-lo
‫o melhor que pudermos.
‫De qualquer forma, fico feliz em ver que você
‫chegou ao final desse grande vídeo,
‫e vejo você no próximo.