Transformação Digital nas empresas

Se você está trabalhando com TI ou ao menos atuando no mundo corporativo assim como eu, certamente você já deve ter ouvido falar em Transformação Digital. Toda semana os principais sites de negócios comentam que a empresa X está fazendo sua transformação digital com a consultoria Y. Ou que a empresa W avança em sua transformação digital através da estratégia de implantar os processos ABC e a solução XPTO.

Mas será que é isso que significa fazer uma transformação digital? Implantar um ERP de mercado? Mudar para processos mais ágeis? Contratar uma consultoria boutique?

Afinal o que é uma transformação digital? O que é uma empresa digital?

Pensando em auxiliar quem está tentando descobrir as respostas para estas perguntas, no artigo de hoje trago algumas definições, estudos de mercado e experiências próprias, com o mínimo de achismo possível e o máximo de fatos e conceitos consolidados. Eu não inventei estas teorias e vários trechos eu li em outros lugares, sendo que informarei os links originais ou citarei o autor sempre que possível.

Curso de Scrum e Métodos Ágeis

O que é Transformação Digital?

Esse é um termo que está cada vez mais famoso no Brasil, certo?

Mesmo por aqui, Transformações Digitais estão eclodindo em todas grandes empresas que não querem ficar de fora da profusão de matérias sobre o tema e da atenção dos investidores. No entanto, ser digital está longe de apenas informatizar processos manuais e trocar tecnologias, exige um redesenho da organização e uma evolução de sua cultura, dois elementos muito mais delicados.

A questão é que transformações de negócios, de qualquer tipo, são extremamente custosas e arriscadas. Para um negócio se tornar digital, não basta adicionar uma camada de tecnologia ou executar o desenvolvimento de software, você tem de inserir a mesma nas entranhas das camadas já existentes. Não é algo que você resolve investido no departamento de TI da empresa, mas distribuindo a TI por toda a empresa. Ou então o contrário, distribuindo business por toda TI. Não importa.

Não ajudei muito até aqui, certo? Calma, vai melhorar.

Muitas corporações estão se deparando com a necessidade de uma transformação digital, mesmo sem saber direito o que é uma. 

De acordo com uma pesquisa de 2017 da CEB chamada “The New IT Operating Model for Digital”, dois-terços dos líderes de negócios acreditam que suas empresas vão perder competitividade se eles não se tornarem significativamente mais digitais. Eles entendem que a sobrevivência de suas empresas depende da sua habilidade de se adaptar a esse novo modelo da economia digital.

Mas o que é ser digital?

A versão online do dicionário Merriam-Webster oferece várias definições para o vocábulo “digital” e duas delas tem a ver com as transformações que estão acontecendo: “dados na forma de dígitos binários” e “interação tátil com os dedos”.

Digital
Digital

Tecnicamente, quando falamos de transformação digital expandimos esses dois conceitos básicos para mais quatro (segundo Phillipe Assouline, da InfoQ):

  • Experiência do Cliente (CX)
  • Cybersegurança
  • Automação
  • Mídias Sociais
Digital Expandido
Digital Expandido

Sendo assim, uma empresa digital é, por essas verticais, aquela que:

  • possui sistemas digitais;
  • sistemas estes de interação fácil e intuitiva (pra não ficarmos preso ao tátil);
  • cujos clientes (internos e externos) possuem uma boa experiência;
  • se preocupa com segurança cibernética;
  • possui processos automatizados;
  • entende e se comunica com seus clientes através de plataformas sociais;

Uma empresa que deseja se tornar digital deve considerar esses seis verticais de prioridades na hora de compor a sua “estratégia digital”. Estratégia essa que pode ser mais ou menos agressiva, mais ou menos intensa, mais inclinada para um vertical e menos para outro, mas sem negligenciar qualquer um deles.

Estratégia de Transformação Digital

No seu famoso Digital Transformation Guide, Assouline menciona que toda empresa passando por uma transformação digital está em um de três estágios: Going, Becoming ou Being Digital e que a jornada de transformação é justamente ir do primeiro estágio ao terceiro.

Jornada Digital

O autor entende que absolutamente TODAS empresas estão aptas a saírem da inércia e chegarem aos estágios um e dois, sendo que o dois é a famosa Transformação Digital que tanto se fala, onde sistemas, processos, comunicação, experiência do cliente e segurança são aperfeiçoados.

E aí que mora uma falha comum na definição da estratégia digital, ou melhor, na falta de UMA!

Ao invés de planejar como sairemos da inércia para um plano de transformação digital (estágio um, Going Digital) é comum vermos executivos mudando sistemas e implantando novos processos por toda empresa, sem entender o que se está buscando com cada mudança e como elas se conversam entre si, causando um caos completo e banalizando o termo “digital” como algo hipster que está na moda mas que não traz valor algum, coisa de empresa que gasta dinheiro para parecer cool.

O autor afirma que uma empresa digital está mais relacionada à conectividade da empresa com o mercado e a sua capacidade de entregar valor de maneira rápida e barata na ponta do que a adoção de novas tecnologias por si só.

Entender o nível desejado de união entre negócios + tecnologia que se quer alcançar é a chave para planejar, mapear e comunicar a intenção da organização com a transformação digital que se deseja iniciar. Para isso, Assouline, que é Head de Data Science e Market Insights em uma grande consultoria, criou um modelo de planejamento, representado na imagem abaixo, que ele chama de DTF: Digital Transformation Framework.

Digital Transformation Framework
Digital Transformation Framework

Por este framework, temos que a base de toda transformação digital deva ser a segurança cibernética (de comunicação e relação automática com os seres humanos), sustentando três pilares.

O primeiro pilar, Tema Digital, é fortemente baseado na definição do que é ser digital que comentei lá em cima, desdobrados em seis temas que fazem sentido para uma empresa fictícia. Enquanto que User Experience, Automation e Social Media são transcrições literais dos verticais abordados anteriormente (além da própria fundação de cybersecurity), Cryptography, Cloud Computing e IoT são demandas específicas da transformação digital de exemplo.

O autor não menciona isso explicitamente, mas menciona de leve que qualquer um dos temas devem ser substituídos pela sua estratégia de transformação, usando os verticais originais como base e as tendências atuais de mercado. Também é interessante notar que uma transformação pode ser faseada, e diferentes temas ou os mesmos temas com intensidades diferentes podem ser abordados em cada fase, como na metodologia Toyota Kata.

Só para citar como exemplo, no Agibank, onde trabalhei de 2017 a 2019 como Agile Coach, os temas da transformação digital eram 4: Infraestrutura Híbrida, Cybersegurança, Business Agility e Arquitetura Corporativa. Obviamente eu trabalhava focado no tema #3 e apenas apoiava o #2 e #4.

O segundo pilar, Orientação ao Cliente, te ajuda a definir se a estratégia é focada no cliente externo ou interno. Este framework assume que a estratégia digital pode ser composta por várias sub-estratégias, ou seja, podemos ter alguns temas que serão dedicados ao cliente externo em uma estratégia e outros temas ao cliente interno, por exemplo.

O terceiro pilar, Nível de Competência, cruza com os Temas Digitais, onde define-se qual o nível de competência a empresa irá buscar em cada um dos temas definidos para sua transformação digital, considerando três possíveis níveis: Competitivo, Indústria e Mínimo.

  • o nível Competitivo demonstra que a empresa deseja ser referência no tema específico e para isso investirá tempo e dinheiro acima da média do mercado; será um diferencial competitivo;
  • o nível Indústria demonstra que a empresa deseja atender aos padrões de mercado, às expectativas comuns para este tema em sua área de atuação; deseja se equiparar aos seus competidores;
  • por fim, o nível Mínimo demonstra que a empresa deseja apenas alcançar o mínimo de competência, entendendo que estará abaixo de seus concorrentes neste tema, mas que não o deixará desassistido;

Seguindo esta explicação do framework e continuando com o exemplo de transformação anterior, podemos plotar o segundo resultado usando o DTF, como uma proposta de transformação digital (totalmente hipotética, baseado nas necessidades e situação de um cliente fictício).

DTF Preenchido
DTF Preenchido

Neste exemplo do DTF preenchido temos uma estratégia composta por duas sub-estratégias, conforme explicação a seguir.

A estratégia 1 (verde claro) é de investir pesado em automação de processos para clientes externos (finais), tornando-se extremamente competitivo neste campo, acima de seus competidores, enquanto que a UX destes mesmos clientes externos deva atender às exigências do seu mercado, equiparando com seus concorrentes.

Já a estratégia 2 (amarelo) é de atender às exigências médias de mídias sociais para sua área de atuação com os clientes externos (talvez esta empresa não se comunicava com os clientes por redes sociais) e oferecer o mínimo de infraestrutura em nuvem para os clientes internos (talvez alguns ambientes para os time de tecnologia).

Essas duas estratégias não abrem mão de segurança digital, não sendo uma opção investir ou não nesse tema.

No próximo artigo, vou explorar como desdobrar esta estratégia em ação na sua empresa, ainda usando o framework DTF de Phillipe Assoulini.

Quer um material de referência para Transformações Ágeis em empresas? Conheça meu livro sobre o assunto clicando no banner abaixo.

Livro para Agile Coaches

Lean Inception: concepção de produtos enxutos

Lean Inception
Lean Inception

Atualizado em 26/01/2020!

A Lean Inception é uma técnica de concepção de produtos enxutos criada por Paulo Caroli, consultor da ThoughtWorks. É um método bem popular entre os agilistas brasileiros e é fortemente documentada no livro Lean Inception, do mesmo autor.

Caroli conta em suas palestras e livros que até então as inceptions (reuniões para concepção de um novo produto) duravam mais de um mês na TW e como Caroli atuava como consultor, não raro ele tinha de passar várias semanas por mês fora de casa, fazendo inceptions em clientes. No entanto, quando seu filho nasceu, ele decidiu que não mais ficaria tanto tempo longe da sua família e construiu uma técnica que, em apenas uma semana, é possível definir tudo que é necessário para se conseguir de fato tangibilizar um produto para que tenhamos insumos suficientes para o time de desenvolver começar a trabalhar.

Lean Inception, Sprint 0, Pré-Jogo…

A Lean Inception ocorre logo no início do projeto, no período que antecede a primeira sprint do time de desenvolvimento, período popularmente chamado de Sprint 0 ou Pré-Jogo. Embora o Scrum não aceite a existência de uma Sprint 0, é comum que isto aconteça de fato logo no início de grandes projetos onde a incerteza é tão grande que não vale a pena iniciar o desenvolvimento às cegas.

A ideia central da Lean Inception é fornecer momentos únicos de interação entre os membros do time e os stakeholders para definição dos conceitos elementares do produto, suas funcionalidades, jornadas do usuário, escopo das entregas, roadmap, etc. Tudo em uma semana muito intensa onde a cada dia novas atividades são realizadas e documentadas.

A ideia deste artigo é dar uma resumida no processo completo, cabendo aos interessados em aplicar esta dinâmica na prática buscar os livros do Caroli ou os treinamentos dele e dos treinadores certificados, como a Mayra Souza. O resumo do treinamento que fiz com esta última pode ser visualizado no vídeo abaixo.

Dia 0: Antes de Começar

O trabalho da Lean Inception começa antes do primeiro dia de dinâmicas. Você terá de montar um grupo heterogêneo de profissionais que possam colaborar com a definição do MVP do produto (objetivo final da inception) ou que estejam diretamente interessadas na construção do mesmo (usuários-chave ou stakeholders, por exemplo). Converse individualmente com cada uma destas pessoas e faça o convite pessoalmente, explicando a importância do comparecimento em todos os dias, como que funciona o processo, etc.

Monte uma lista de emails contendo o contato de todos os membros do grupo e dias antes da inception já comece a lembrá-los de que ela vai começar em breve. Certifique-se que seu grupo tenha até 30 pessoas e que tenha facilitadores suficientes para dar conta desta galera toda, em média 1 facilitador para cada 10 pessoas. Os facilitadores não executam as atividades, apenas conduzem, sem influenciar. Também garanta que todos os perfis abaixo estejam presentes neste grupo:

  • Product Owner do produto;
  • Scrum Master do time (geralmente um dos facilitadores);
  • profissionais técnicos do time (programador, analista, etc);
  • profissionais criativos de UX, UI, marketing, etc;
  • profissionais das áreas de negócio da empresa;
  • profissionais das áreas de atendimento da empresa;
  • usuários-chave do sistema;

Dia 1: Segunda-feira

Como a inception dura a semana inteira, o ideal é que ela comece em uma segunda-feira, para que não aconteça quebra de raciocínio. Mande um email reforçando o início da inception para todos os convidados e tenha um ambiente minimamente dedicado para que a dinâmica aconteça todos os dias no mesmo local e com os mesmos materiais, para que nada se perca entre cada um dos dias.

No primeiro dia as regras da inception são explicadas e em alto nível o que é a ideia do produto (geralmente o Product Owner dará este briefing). Geralmente pede-se que todos os membros do grupo se apresentem, expressem suas expectativas e faz-se uma dinâmica de energização para quebrar o gelo e animar o pessoal. Paulo Pontual, Zip-Zap-Zum, entre outras são sugeridas.

São formados grupos de trabalho, geralmente de 2 a 5 e na parte da manhã a primeira atividade é escrever a Visão do Produto. Cada time escreve a sua visão usando o template abaixo:

Para [cliente final],

cujo [problema que precisa ser resolvido],

o [nome do produto]

é um [categoria do produto]

que [benefícios-chave, razões para comprá-lo].

Diferente do [alternativa de mercado],

nosso produto [diferença-chave].

Depois, cada grupo apresenta a sua versão da visão do produto e ao término das apresentações, consolida-se em apenas uma só, gerando debates para que esta consolidação gere o melhor resultado. Documente a Visão do Produto com fotografias, isso será útil mais tarde, e preferencialmente transcreva-a para um cartaz que deverá estar fixo na sala da dinâmica a semana inteira.

Product Vision
Product Vision

Na parte da tarde (que tal uma energização após o almoço?) faz-se a dinâmica de definição do produto, também chamada de É-Não É, Faz Não-Faz. Aqui a ideia é que cada grupo trabalhe em um cartaz dividido em 4 quadrantes: É, Não É, Faz, Não Faz.

É-Não É-Faz-Não Faz
É-Não É-Faz-Não Faz

Em cada quadrante os membros do grupo discutem o que o produto é, o que ele não é, o que ele vai fazer e o que ele não vai fazer. Depois que cada grupo cria as suas definições individualmente, novamente cada grupo apresenta e o resultado final é consolidado em apenas uma versão após várias rodadas de discussão envolvendo cada quadrante.

As evidências destas duas dinâmicas são enviadas a todo o grupo no final do dia, bem como quaisquer outras fotos tiradas e uma descrição rápida de como o dia passou. Caso não seja possível deixar os cartazes consolidados nas paredes da sala, o facilitador deve guardar os mesmos para que seja possível manter o histórico da dinâmica completa.

Livro para Agile Coaches
Livro para Agile Coaches

Dia 2: Terça-feira

Começa-se o segundo dia reforçando o compromissos com todos via email, antes mesmo da dinâmica começar. Quando a dinâmica começa de fato, após a energização/quebra-gelo (sim, sempre faz-se uma no início do dia) inicia-se uma recapitulação do dia anterior, mostrando o produto final das dinâmicas de Visão do Produto e da É-Não é-Faz-Não Faz, para que todos estejam na mesma página novamente.

Uma vez que temos em alto nível os conceitos mais fundamentais do produto, é hora de falarmos de quem vai usá-lo/comprá-lo: as personas. As personas são arquétipos de usuários-chave típicos do produto. Cada produto possui no mínimo uma persona, enquanto que alguns podem possuir várias.

Cada grupo de trabalho pega uma persona para trabalhar, preenchendo um cartaz com os quatro quadrantes sobre a persona que escolheram:

  • nome e retrato: qual o nome ou apelido deste usuário-chave do produto? como ele se parece, se veste, etc?
  • perfil: idade, nacionalidade, etnia, renda, formação, profissão, etc
  • comportamentos: hobbies, crenças limitantes, crenças fortalecedoras, etc
  • necessidades: o que ele está buscando? Quais as suas dificuldades? As suas “coceiras”? As suas aspirações?
personas
personas

Uma vez que um produto pode ter várias personas, pode ser que cada grupo fique com uma diferente, não havendo necessidade de consolidação. Caso alguma persona se repita, deve-se consolidar os resultados obtidos para a mesma persona. De qualquer forma, cada grupo apresenta aos demais os resultados obtidos.

No mesmo dia, na parte da tarde, é hora de fazer a Descoberta das Features. Uma feature ou funcionalidade é a descrição de uma interação do usuário com o produto ou alguma ação que o sistema é capaz de realizar. As descrições das features devem ser simples e sem entrar em detalhes técnicos.

Para fazer esta descoberta de features existem diversas dinâmicas possíveis, desde simples brainstormings até entrevistas com usuários-chave. A técnica sugerida pela Lean Inception é fazer uma matriz onde cada coluna é algo que o sistema faz (lembra do Faz-Não Faz?) e cada linha é uma persona. O cruzamento das personas com o que o produto faz deve induzir às features necessárias.

Personas x Features
Personas x Features

Note que esta matriz é para ajudar o raciocínio para a descoberta de features, não para limitar a criatividade das pessoas nem para obrigar a fazer todas as combinações de coisas que o produto faz com as personas existentes. No entanto, é sempre interessante descartar features neste momento que de fato não auxiliem na resolução de nenhuma necessidade das personas, direta ou indiretamente.

Ao final do dia, tiram-se fotos dos cartazes das personas e do resultado da descoberta de features. É interessante também adicionar uma numeração nas features para facilitar a organização posterior. Envia-se um email a todos envolvidos com as evidências da dinâmica.

Este artigo ia ficar muito grande, resolvi quebrar em duas partes, sendo que a segunda parte está neste link. Para se aprofundar no assunto, leia o livro do Caroli, abaixo. Para mais conteúdo sobre Métodos Ágeis de desenvolvimento de software, recomendo o meu livro Scrum e Métodos Ágeis: Um Guia Prático e o meu curso sobre o mesmo assunto.

Curso de Scrum e Métodos Ágeis
Curso de Scrum e Métodos Ágeis

Autenticação em Node.js com Passport

Atualizado em 24/01/2020! Caso queira ver este artigo em formato de vídeoaula, adquira o meu curso de Node.js e MongoDB.

Recentemente escrevi um tutorial onde ensino como fazer uma aplicação de chat usando Node.js e Socket.io. Na última parte do tutorial, dou uma série de ideias de coisas que podem e/ou devem ser feitas para deixar a solução mais profissional, independente se você está apenas estudando ou trabalhando com a tecnologia. Em outros tutoriais, também ensinei a fazer CRUDs completos usando Express e diversos bancos de dados, relacionais (como MySQL e SQL Server) e não-relacionais.

Ou quase completos, afinal, eu sempre pulo a parte da autenticação.

Verdade seja dita, é difícil um sistema web que não tenha algum tipo de identificação, mesmo que você não veja como uma medida de segurança em si. A Internet é uma espécie de terra sem lei, e mesmo em serviços gratuitos, como os do Google, a autenticação garante que abusos serão evitados ou ao menos controlados.

Dito isso, hoje veremos como fazer autenticação de aplicações e APIs web com Node.js usando Passport!

  1. A aplicação web
  2. Escolhendo a tecnologia de autenticação
  3. Configurando o banco de dados e variáveis de ambiente
  4. Programando sua estratégia de autenticação
  5. Configurando o projeto para autenticação
  6. Fazendo o login funcionar

Este e outros tutoriais incríveis podem ser vistos em videoaulas no meu curso de Node.js e MongoDB.

#1 – A aplicação web

Minha sugestão: faça o tutorial de como criar um chat usando Node.js e Socket.io primeiro, pois partirei dele aqui. Você também pode usar os ensinamentos deste post em outra aplicação, as mudanças são bem sutis, vou sinalizar elas no texto. E você pode também baixar os fontes do referido tutorial para poder acompanhar.

Primeiro passo de preparação da nossa aplicação para ter autenticação: criar uma tela de login!

Crie na sua aplicação uma nova view chamada login.ejs com o seguinte HTML dentro:

Note que deixei um código de servidor verificando a existência de uma message no model, para renderizar uma label de erro ali embaixo. Usaremos isso mais tarde para avisar de erros de autenticação. Também deixei dois links, um para recuperação de senha e outro para cadastro, sendo que mais tarde criaremos estas duas telas e seus funcionamentos.

E na sua rota index.js, modifique a rota raiz para renderizar esta view, afinal, não estávamos usando aquela página inicial para nada mesmo!

Com isso, ao entrar na aplicação de chat, obrigatoriamente o usuário verá primeiro a tela de autenticação. Obviamente isso não inibe ninguém de acessar páginas internas através da URL do navegador, mas um problema de cada vez, por favor!

Tela de Login
Tela de Login

Programaremos o seu funcionamento mais pra frente.

#2 – Escolhendo a tecnologia de autenticação

Neste tutorial usarei o módulo Passport, que é o padrão quando o assunto é autenticação em Express, o webframework que é padrão quando o assunto são webapps em Node.js, a plataforma que é padrão quando o assunto… (e assim por diante). No entanto, Passport está longe de ser uma bala de prata quando o assunto é segurança nas suas aplicações. Passport é apenas um middleware de segurança que exige que os desenvolvedores saibam o que estão fazendo e que programem a segurança do jeito que quiserem, sendo muito flexível, extensível e de uso comum no mercado.

Neste tutorial, tentarei ser o mais profissional possível em termos de segurança considerando que muitos leitores costumam usar os códigos que forneço/ensino em seus sistemas, no entanto, vale a ressalva de sempre ser crítico e cético quanto a códigos da Internet, especialmente aqueles que podem danificar o seu sistema como a camada de segurança.

Outras opções de autenticação existem aos montes na Internet, principalmente as baseadas em padrões web e através de APIs, o que lhe eximem muitas vezes a responsabilidade de uma série de tarefas burocráticas de se ter autenticação em sua aplicação, como autenticar, armazenar senhas, cadastro de usuários, recuperação de senhas, etc. Nomes como Google Account, Microsoft Account, Facebook Authentication, Auth0 e até mesmo Firebase possuem soluções para isso, sem contar Github, Twitter e a lista vai longe. São todas excelentes opções mas que eventualmente te engessam em algumas questões e te torna dependente das empresas em questão.

Sendo assim, optarei aqui pelo Passport não por ele ser a melhor solução de autenticação do mercado, mas por ser aberto, extensível, flexível, etc. E por ter uma boa adesão do mercado quando o assunto é Node.js.

#3 – Configurando o banco de dados e variáveis de ambiente

Os dados de sessão dos usuários vão ficar armazenados em um banco MongoDB (embora também seja possível usar Redis como alguns tutoriais ensinam por aí). Eu já expliquei tudo que você precisa saber sobre como configurar o ambiente MongoDB pra uso com Node neste tutorial e caso não esteja com tempo agora, sugiro apenas que crie uma conta na Umbler, crie um site Node.js e use o serviço de MongoDB deles usando os créditos que você ganha quando se cadastra.

Voltando ao nosso projeto Node.js, instale o driver do MongoDB para Node:

Agora instale o módulo dotenv-safe, que permitirá guardarmos variáveis de ambiente de uma maneira muito prática e profissional, permitindo fazer deploy do nosso projeto em produção sem ter de ficar trocando connection strings e coisas do tipo:

Pra que o dotenv-safe funcione (ensino em videoaulas do meu curso de Node.js e MongoDB), você precisa criar dois arquivos: “.env” e “.env.example”. O “.env.example” é o template contendo quais variáveis de ambiente são obrigatórias para sua aplicação funcionar, em nosso caso, apenas duas:

Já o “.env”, contém a sua versão local das variáveis e o ideal é que você inclua no seu .gitignore o .env, para que ele não seja commitado em produção (em produção você deve setar as variáveis de ambiente de produção, e não vai querer elas sobrescritas de maneira alguma):

Agora modifique o seu bin/www (geramos este projeto com o express-generator, lembra?) para que o servidor somente seja iniciado após a conexão com o banco de dados tiver sido realizada, como abaixo (obviamente informe os dados da sua conexão com o banco), onde uso a variável de ambiente como connection string:

O objeto db é a conexão com o banco e vamos compartilhá-lo globalmente com os outros módulos que precisarem (apontando diretamente para o banco configurado na variável de ambiente). Caso o .env não exista, teremos um erro. Caso não consiga se conectar ao banco, teremos um erro. O projeto somente vai “subir” se estiver tudo 100%.

Se você rodar este projeto agora e tudo estiver 100%, você deve ver a mensagem no console de que a conexão foi bem sucedida.

Antes de prosseguirmos, é de bom tom cadastrarmos no mínimo um usuário em nosso banco de dados, para poder realizar os testes depois. Acesse o seu banco MongoDB local ou remoto e insira na coleção users um usuário com os seguintes dados:

Coloque no campo email, um email seu de verdade, pois precisaremos dele funcionando mais tarde. Note que o password do usuário está criptografado. Esta senha na verdade é uma versão criptografada da palavra “123”. 🙂

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

#4 – Programando sua estratégia de autenticação

Agora que temos o banco de dados funcionando podemos definir a nossa estratégia de autenticação. Vamos fazer isso em um novo arquivo chamado auth.js na raiz do nosso projeto.

Mas antes de mexermos neste arquivo, vamos instalar e mexer em duas dependências que precisaremos.

Lembra quando falei que o Passport era bacana por ser extensível? A estratégia de autenticação é completamente configurável, desde os padrões de terceiros, até padrões abertos como OAuth ou o clássico username/password. Aqui vamos instalar o módulo passport-local, que define como estratégia o uso de usuário e senha armazenados em nosso próprio banco para funcionar (clássico username/password):

E vamos também instalar o módulo bcrypt para manter nossas senhas seguras no banco de dados. Armazenar hashs das senhas ao invés de texto plano no banco de dados é uma política mínima visando segurança das informações.

Atenção: caso o módulo acima falhe na instalação, use bcryptjs no lugar. Neste caso o seu require será em cima de bcryptjs, mas os demais códigos deste tutorial funcionam normalmente.

Agora sim vamos voltar ao nosso auth.js e carregar estes dois módulos, além de definir o nosso module.exports que vai configurar (em uma espécie de inversão de controle) o objeto do passport (que é o middleware de autenticação) que criaremos mais pra frente:

Note o comentário ali dentro da function exportada: é ali que vamos trabalhar agora.

Primeiro, crie ali dentro duas functions de busca de usuário em nossa base Mongo. Precisamos das duas para fazer nossa autenticação funcionar, você já vai ver porque:

A primeira função busca um usuário por username e passa o retorno para uma função de callback. Já a segunda busca por id e também passa o retorno por callback.

Por questões de segurança e praticidade ao mesmo tempo, o cookie de autenticação (que falarei melhor mais tarde) não conterá as informações da sessão, as mesmas ficarão no banco e teremos apenas o id localmente nos clientes. Assim, precisamos configurar as funções de serialização e desserialização de usuário ainda dentro daquele espaço de exportação desse módulo:

A função done é “nativa” do passport e serve para sinalizar erro e passar informações do usuário para o passport. Na função serializeUser, passamos a chave primária (ObjectId do MongoDB) para ser serializado no cookie do usuário. Já no deserializeUser, recebemos o id e vamos com ele no banco de dados retornar o usuário inteiro.

E por fim, vamos definir a estratégia de autenticação em si, chamada de LocalStrategy, ainda no final do espaço do module.exports:

Vamos por partes aqui pois é bastante coisa:

  • usernameField e passwordField são os names dos inputs no form HTML que será postado durante a autenticação;
  • a function findUser é a que criamos anteriormente que vai no MongoDB buscar usuário por username;
  • se der erro ou se não existir aquele username, avisamos ao passport que não rola essa autenticação através da função done;
  • se o usuário existir, usaremos o bcrypt.compare entre a senha digitada no form de login (password) e a senha salva (hash) no banco de dados;
  • o retorno dessa comparação também é sinalizado ao passport via function done.

Com isso finalizamos nosso módulo com a estratégia de autenticação. Uma versão mais parruda desse módulo poderia contabilizar o número de tentativas erradas para pedir que o usuário solucione um Captcha, bloquear o usuário, avisar o usuário quando um login de novo IP acontecer, etc.

#5 – Configurando o projeto para autenticação

Basicamente quando um usuário entra na página inicial do seu webapp, ele não está autenticado, está iniciando uma sessão anônima. Para que ele possa entrar nas páginas seguras do seu webapp, ele deve estar autenticado, em uma sessão autenticada. Essa autenticação ocorre durante o processo de login, onde usando credenciais válidas (usuário e senha, por exemplo), a sessão do nosso usuário recebe um cookie identificando-o. Nos demais acessos, esse cookie é verificado para conceder ou não autorização para navegar entre as páginas.

O uso de cookies e sessões é o jeito mais comum de garantir que um usuário está autenticado em páginas web e é o que usaremos aqui. Antes de mexer com eles, vamos adicionar o módulo passport em nosso projeto, com o comando abaixo (curioso como já falamos bastante nele mas só agora adicionamos no projeto):

Para manipular a sessão de aplicações web feitas usando Express usaremos o módulo express-session, instalado usando o comando abaixo na raiz do seu projeto:

Para uma abordagem mais escalável e profissional, nosso cookie de sessão não vai armazenar todos os dados da sessão, mas sim apenas seu ID, enquanto que os demais dados estarão em nosso MongoDB que já está prontinho.

O express-session permite armazenar os dados da sua sessão em diferentes mecanismos de persistência, desde que usando os conectores adequados. Como vamos usar Mongo, instale também o módulo de persistência de sessão para MongoDB:

Com isso, agora podemos configurar a nossa aplicação, abra o app.js e adicione as seguintes linhas no topo dele:

Isso apenas declara e inicia nossos módulos recém instalados. Agora vamos adicionar estas linhas para passar a usá-los no app.js, logo no bloco onde você vê vários app.use juntos:

Aqui estou carregando nosso módulo auth.js passando o objeto passport pra ele configurar a estratégia de autenticação. Depois digo para o express-session usar a mesma conexão MongoDB já inicializada com nossa aplicação e que os dados de sessão devem ser apagados automaticamente após 30 minutos, um recurso nativo do MongoDB chamando TTL Index.

Os campos resave e saveUnitialized eu optei por deixar como false para não onerar demais o banco. O primeiro ressalva o cookie de sessão a cada requisição, enquanto que o segundo salva dados de sessões anônimas também. Caso precise de algum deles, apenas mude para true.

E com isso deixamos nossa aplicação ‘pronta’ para receber autenticação, embora que se você rodar esse projeto agora, tirando a tela de login que vai abrir automaticamente, não há segurança alguma ainda.

#6 – Fazendo o login funcionar

Com isso, podemos agora voltar para o arquivo index.js que receberá os posts da tela de login e realizará a verificação de usuário e senha junto ao passport (que vai usar a estratégia que configuramos anteriormente). Vale lembrar que qualquer sistema com o mínimo de segurança deve estar utilizando SSL para que os dados postados pelo formulário não sejam facilmente capturados e lidos na rede (se estiver usando a dica que dei de usar a Umbler, você pode ativar SSL gratuito e de qualidade da Let’s Encrypt ou da CloudFlare).

Primeiro, vamos carregar o passport no index.js, lá no início e vamos adicionar uma function que vai ser muito útil depois para não deixar usuários anônimos acessarem as páginas internas da aplicação:

Chamaremos essa função authenticationMiddleware toda vez que uma requisição solicitar uma página que não seja as públicas (como login). Basicamente ela verifica se a requisição está autenticada (isAuthenticated), caso contrário joga o usuário anônimo para a tela de login com a flag de falha.

Agora vamos criar duas novas rotas nesse arquivo:

A primeira, é um GET /login que devolve uma mensagem apropriada conforme a flag de erro na querystring existir ou não. Você pode aperfeiçoar este comportamento para diferentes mensagens de acordo com diferentes códigos de erro ou coisas do tipo.

Já a segunda function captura requisições POST /login passando ao passport a tarefa de autenticar usando a estratégia local. O objeto de configuração passado como segundo parâmetro da função authenticate define as URLs de sucesso e de falha, conforme o resultado que o passport definir. Note que ali o sucesso redireciona para ‘/chat’, mude para o path adequado da sua aplicação.

Agora, para finalizar essa primeira (e extensa) etapa para criar autenticação profissional com Node.js, precisamos apenas garantir que nenhum usuário anônimo possa acessar a tela de chat do sistema. Para isso, usaremos nossa function authenticationMiddleware como um intermediário entre as requisições GET para as telas privadas da nossa aplicação, que deve ficar como abaixo onde usei como exemplo a rota ‘/chat’ (mude de acordo com sua aplicação):

Também aproveitei e passei o username que acabou de se autenticar como model dessa view para ser usado mais tarde.

Sim, mais tarde. Continuaremos com as demais funcionalidades necessárias para um sistema de login completo como recuperação de senha e cadastro de usuário.

Por ora, você pode cadastrar usuários manualmente (ou usar o adm/123 que pré-cadastramos antes) usando alguma ferramenta bcrypt online para gerar o hash da senha. Depois teste a sua tela de login para ver se ela aceita suas credenciais, se ela redireciona corretamente, tente acessar a tela de chat (ou a tela privada que você definiu) sem fazer login antes ou até mesmo diminua o TTL da sua sessão para ver se ela expira sozinha e te manda de volta para o login.

Erro no Login
Erro no Login

Está funcionando e você confere a segunda parte deste tutorial neste link!

Connection strategy not found

Se você tiver esse erro, essa resposta aqui ajudou alguns alunos: https://stackoverflow.com/questions/34822381/error-connection-strategy-not-found-mongodb.

Curtiu o post? Então clica no banner abaixo e dá uma conferida no meu livro sobre programação web com Node.js, onde você encontra este mesmo material em formato de videoaula!