Autenticação em Node.js com Passport – Parte 3

Este artigo é uma continuação da parte 2 do meu tutorial de autenticação em Node.js usando a biblioteca Passport. Nessa terceira parte veremos como fazer um recurso bem simples de recuperação de senha via email e de logout do usuário autenticado.

Caso você deseje ver este artigo em vídeoaula, saiba que ela está disponível em meu curso online de Node.js e MongoDB.

Vamos lá!

Criando a recuperação de senha

Agora a próxima parte é a de recuperação de senha. Lembra que deixamos um link pra isso lá na tela de login?

Vamos começar criando uma nova view, a views/forgot.ejs, com um formulário bem simples que pede a confirmação de seu email para envio de uma nova senha:

E para que essa tela seja acessível, vamos criar uma nova rota GET em routes/users.js:

Rodando sua aplicação e acessando no navegador, já deve ser possível navegar até esta página usando o link na tela de login:

Esqueceu a senha
Esqueceu a senha

Para fazer funcionar este formulário, vamos começar criando duas funções em nosso arquivo db.js: uma que busca um usuário pelo seu email e outra que muda a senha de um usuário:

A primeira função é bem simples, um findOne por email, que executa um callback após encontrar (ou não) o usuário. A segunda recebe uma senha, criptografa ela e sobrescreve o hash de senha do usuário cujo id foi passado por parâmetro. O module.exports no final do db.js também foi atualizado de acordo.

Note que não estou criando as devidas validações em nenhum formulário para os artigos não ficarem gigantescos. Nem de campos obrigatórios, nem validações de regras de negócio como não permitir usuários e emails duplicados. Tenha em mente que você deverá implementar essas questões se for usar esses códigos em produção.

Antes de sairmos fazendo a rota POST, vamos criar um arquivo utils.js na raiz do nosso projeto e colocar dentro dele uma função de geração de senha aleatória:

Esta função é bem simples e talvez você até queira usar alguma mais avançada. Aqui eu crio e retorno uma senha aleatória de 10 caracteres alfanuméricos (maiúsculas, minúsculas e números).

Agora que temos estas funções podemos criar a nossa rota POST que vai receber os dados do formulário de “esqueci minha senha”. Abra o arquivo routes/users.js e crie a nova rota:

Aqui começamos com o findUser que criamos anteriormente, que busca usuário por email. Caso não encontre, vamos jogar o usuário para a tela de login mesmo assim, embora você possa pensar em algo mais criativo para fazer.

Caso encontre, mandamos gerar uma nova senha usando a função que criei há pouco e uso o changePassword para mudar a senha do usuário que possui o email especificado (em um sistema de produção, para evitar problemas, além do email, peça alguma informação pessoal do usuário para confirmar esse processo de troca de senha). Por fim, um email é enviado com a senha que acabou de ser gerada, como na imagem abaixo.

Nova senha
Nova senha

Se você tentar se autenticar com a senha antiga, notará que ela não funciona mais, somente a nova.

É uma boa prática guardar o hash das últimas senhas do usuário e não deixar que ele use senhas antigas (mesmo senhas aleatórias podem conflitar ocasionalmente). Outra boa prática seria no primeiro login com a nova senha ele ser solicitado a cadastrar uma senha pessoal ao invés dessa aleatória. Enfim, sempre há margem para melhorar quando o assunto é segurança.

Está curtindo o post? Para uma formação ainda mais completa como programador web recomendo meu livro sobre programação web com Node.js clicando no banner abaixo!

Logout

Até o momento nos preocupamos em autenticar os usuários que desejam entrar no sistema. Mas e os usuários que desejam sair? Como podemos implementar uma funcionalidade de logout na nossa aplicação?

Muito simples!

Na view index.ejs (ou onde quiser), adicione um form HTML com um botão que fará um post em uma rota logoff, como abaixo:

Agora é hora de criarmos esta rota, o que devemos fazer em routes/login.js, nosso módulo de rotas de autenticação. Adicione a nova rota abaixo:

Note que o objeto req (request) possui um método logOut(). Isso porque foi injetada esta função nele através do Passport. Se você executar esta aplicação agora, se autenticar e depois clicar no botão de logoff, não apenas irá voltar para a tela de login, mas não conseguirá acessar a área logada até que se autentique novamente.

Teste e verá que funciona perfeitamente!

Você confere a continuação deste tutorial neste artigo aqui.

Este artigo tem uma versão em videoaula em uma das aulas do meu curso de Nodejs e MongoDB que você confere clicando no banner abaixo.

Curso Node.js e MongoDB
Curso Node.js e MongoDB

Arquitetura de micro serviços em Node.js + MongoDB: Parte 5

Atualizado em 28/09/19!

E chegamos à quinta parte da nossa série de artigos sobre como implementar na prática um projeto de sistema usando arquitetura de microservices usando Node.js e MongoDB. Essa que já é uma das séries de artigos mais longevas aqui do blog!

Segue o índice da série até o momento, caso tenha caído de pára-quedas no blog só agora:

  • Parte 1: introdução teórica e case que estudaremos;
  • Parte 2: estrutura do projeto, camadas de dados e testes unitários;
  • Parte 3: primeiro microservice finalizado (movies-service);
  • Parte 4: iniciando desenvolvimento do segundo microservice (cinema-catalog-service);

Nesta quinta parte, vamos fazer o desenvolvimento das demais funções do repository.js do micro serviço cinema-catalog-service, lembrando que queremos fornecer através deste micro serviço acesso ao front-end mobile a funções como consulta de cinemas por cidade, de filmes em exibição por cinema, sessões dos filmes e por aí vai.

Consulta de Lançamentos do Cinema
Consulta de Lançamentos do Cinema

Veremos nesta etapa da série:

  1. Finalizando o Repositório
  2. Programando a API Cinema-Catalog-Service

Então mãos à obra!

#1 – Finalizando o Repositório

Onde paramos no artigo anterior? Ah sim, tínhamos a seguinte lista de funções a serem criadas no repository.js:

  • pesquisar cidades em que a rede possui cinema;
  • pesquisar cinemas por id da cidade;
  • pesquisar filmes disponíveis em um cinema;
  • pesquisar filmes disponíveis em uma cidade;
  • pesquisar sessões disponíveis para um filme em uma cidade;
  • pesquisar sessões disponíveis para um filme em um cinema;

Enquanto que as duas primeiras foram feitas ainda no artigo anterior, as demais não. Elas guardam uma complexidade que ainda não tivemos de lidar no nosso projeto: agregações. Como nosso documento é relativamente complexo, com mais de um nível de profundidade, se faz necessário navegar e agrupar dados entre os níveis para oferecer informação relevante e fácil de ser manipulada pela camada de API que ainda nem construímos.

Assim, abra o seu cinema-microservice/cinema-catalog-service/src/repository/repository.js e adicione a seguinte função:

Respire por um momento que aqui temos uma série de novos operadores e a novíssima função aggregate.

A função aggregate substitui a função find quando nossa consulta irá manipular os dados resultantes para realizar agregações de diversos tipos. A função aggregate executa um pipeline de comandos contidos no array que ela recebe por parâmetro, seguindo exatamente a ordem do array. Assim, do primeiro operador do nosso pipeline de agregação temos:

  • $match: este operador é um filtro, tal qual os possíveis de serem utilizados no find. Aqui, estou dizendo para filtrar apenas pelos documentos cujo id do cinema seja igual ao recebido;
  • $unwind: este operador desconstrói campos multivalorados em novos documentos, repetindo os demais dados do documento pai do array. Ou seja, se eu tinha uma cidade com dois cinemas dentro, o primeiro $unwind vai fazer com que eu tenha duas cidades repetidas, mas cada uma com um cinema apenas (o campo multivalorado vira univalorado);
  • os $unwinds seguintes vão desconstruindo os demais arrays do documento;
  • $group: uma vez que eu tenho todos os documentos com apenas documentos e subdocumentos (sem arrays), é hora de agrupar eles para evitar as repetições e também para pegar apenas os dados que me interessam, que são os ids e nomes dos filmes que estão em exibição no cinema em questão;

Essa agregação toda, no final das contas, gera um array de filmes no formato id/nome bem simples de ser recebido e utilizado pela API.

Na mesma ideia da função anterior, vamos criar mais três delas, finalizando nosso repository.js:

Note que nestas funções ainda temos mais alguns complicadores.

Primeiro, todas elas estão tratando o retorno da função to Array para passar para o callback objetos mais “mastigados” uma vez que o operador $group do MongoDB costuma deixar um nível desnecessário dentro dos documentos que ele retorna, fora nomenclaturas e etc que podemos tratar melhor usando a boa e velha função ‘map’ do JavaScript.

Além disso, as duas últimas funções usaram um operador $match adicional para fazer um novo filtro após os $unwinds, diminuindo ainda mais a carga do operador $group. Usar o operador $match o quanto antes do final do pipeline de agregação é sempre uma boa prática para diminuir a carga da função aggregate que é bem pesada.

Para finalizar este arquivo, não esqueça de colocar o nome de todas funções no module.exports no final do mesmo:

E ‘bora criar novos testes unitários para cobrir estas novas funções no repository.test.js, como abaixo. Coloque estes testes após o teste da função ‘Repository getCinemasByCityId’ e antes do teste da função ‘disconnect’.

Isso nos dará uma cobertura de 100% das nossas funções, nos dando a garantia que podemos avançar para a camada de API do nosso microservice sem medo de ter deixado alguma ponta solta para trás!

Curso Node.js e MongoDB
Curso Node.js e MongoDB

#2 – Programando a API Cinema-Catalog-Service

Nosso próximo passo é criar a API propriamente dita. Seguiremos a mesma arquitetura da API anterior, a movies-service, apenas definindo um novo conjunto de rotas coerente com a responsabilidade desse microservice novo que é a localização de salas e sessões de cinema a partir de informações como cidade, filme, etc.

Baseado no que temos de funções em nosso repository.js, podemos definir que devemos fornecer o tratamento das seguintes rotas na nossa API:

  • GET /cities
    • lista todas cidades em que a rede possui cinema;
  • GET /cities/:city/movies
    • lista todos os filmes em exibição na cidade especificada;
  • GET /cities/:city/movies/:movie
    • lista todos as sessões do filme escolhido na cidade especificada;
  • GET /cities/:city/cinemas
    • lista todos os cinemas em determinada cidade;
  • GET /cinemas/:cinema/movies
    • lista todos os filmes em exibição no cinema especificado;
  • GET /cinemas:cinema/movies/:movie
    • lista todas as sessões do filme escolhido no cinema especificado;

Novamente vamos adotar a abordagem de não fazer o CRUD completo mas apenas as chamadas que possibilitem ao front-end poder construir suas telas e seu funcionamento de navegação.

Obviamente você pode pensar em rotas adicionais à estas ou até em uma ‘pureza’ maior do conceito de RESTful.

Com esse mapeamento das rotas em mente, vamos criar nosso arquivo cinema-microservice/cinema-catalog-service/src/api/cinema-catalog.js com o seguinte conteúdo que não tem nada demais em relação à API anterior que já criamos (movies-service):

Note que como o trabalho pesado ficou todo no repository.js e suas inúmeras agregações, aqui basta receber a requisição, pegar os parâmetros adequados e chamar a função correspondente no repositório. Simples assim.

Da mesma forma que mencionei em outro artigo desta série, também é necessário aplicar validação dos inputs recebidos, por segurança. Falo sobre isto nesse outro artigo aqui.

Para escrever nossos testes, usaremos como base as mesmas ferramentas e princípios dos testes de API que fizemos na Parte 3 usando a biblioteca supertest como apoio (lembrando que instalamos todas as dependências deste projeto no artigo anterior). Assim, crie o arquivo cinema-catalog.test.js e adicione os seguintes testes dentro dele:

O que tem de novo aqui que valha a pena ser explicado? Absolutamente nada, e espero que a esta altura do campeonato você consiga criar este arquivo e seus testes sem ter de necessariamente copiar e colar este bloco inteiro de código. Caso ainda não consiga, tente ao menos copiar apenas um teste e escrever de próprio punho os demais, para ir pegando prática.

Para verificar se os testes estão funcionando, apenas adicione mais uma linha no nosso índice de testes:

Rode com um ‘npm test’ e se fez tudo certinho, verá uma beleza de bateria de testes tendo sucesso.

Todos testes OK
Todos testes OK

Para finalizar nosso micro serviço precisamos construir o nosso index.js que é praticamente idêntico ao do outro projeto, mudado apenas o módulo da API:

Isso deve ser o suficiente pra fazer o nosso serviço cinema-catalog-service funcionar. Com a criação deste segundo micro serviço, uma série de dúvidas devem lhe surgir, por exemplo, como manter controle dos múltiplos endpoints entre múltiplos microservices? Como garantir segurança de maneira uniforme entre os microservices sem ter de compartilhar dados de usuários autorizados entre todas bases de dados? E porque cinema-catalog-service não consome movies-service como imaginamos inicialmente?

Eu começo a responder estas e outras perguntas nos próximo posts, sobre API Gateways e JSON Web Token, além deste onde falo de boas práticas em arquiteturas de microservices e como refatorar um monolito em micro serviços.

Curtiu o post? Então clica no banner abaixo e dá uma conferida no meu livro sobre microservices com Node.js!