A autenticação com dois factores pode parecer um processo muito banal por parte do utilizador. Muitos estão há muito habituados ao facto de que quando se utilizam muitas aplicações, não é suficiente introduzir uma combinação familiar de login e palavra-chave. Um factor de verificação adicional é introduzido para maior segurança e para impedir o acesso não autorizado. Na maioria dos casos, trata-se de um código único que pode ser recebido por correio electrónico ou SMS.
Neste tutorial, aprenderemos como se pode implementar a autenticação de dois factores em AppMaster. Como exemplo, será utilizado o envio do código para o correio. Analisaremos que módulos necessitam de ser ligados, que definições fazer, que processo comercial criar, e como verificar o resultado final na prática.
Primeiro, vamos dar uma vista de olhos ao plano geral. Que passos precisam de ser implementados no nosso processo empresarial?
- Verificação de login (certifique-se de que o utilizador está efectivamente registado).
- Verificar se a palavra-passe está correcta.
- Envio de um código de confirmação por correio ou SMS.
- Verificação da relevância do código.
- Verificar se o código está correcto.
- Сompletion de autenticação.
Fase preparatória
Mesmo antes de começar a conceber a autenticação de dois factores, na fase de registo do utilizador, é necessário ter a certeza de que:
- Os dados do utilizador devem conter um e-mail. Será utilizado para enviar o código de verificação. O correio electrónico é frequentemente utilizado como login, e vamos olhar apenas para um exemplo.
- O início de sessão é único. Dois utilizadores diferentes com o mesmo início de sessão não podem existir no sistema.
Para a conveniência de resolver estas (e muitas outras) tarefas, o Auth O módulo é instalado por defeito em cada projecto AppMaster. Contém os modelos necessários de bases de dados, blocos de processos empresariais, e pontos finais para a sua utilização.
Verificação do início de sessão
Login, palavra-passe e código de verificação são utilizados como parâmetros de entrada do processo empresarial. Mas na primeira fase, só precisamos de um login. Isso ajudaria a garantir que este utilizador existe. Ele foi registado, e a informação sobre ele é armazenada na base de dados.
Para o fazer, o módulo DB: Search User procura em bloco por um utilizador com o login dado na base de dados. Não se esqueça de definir o SearchExact = True para procurar uma correspondência exacta.
Os dados recebidos são passados para o parâmetro Array Element bloco com índice 0 (a contagem começa a partir de zero, e o único valor encontrado corresponderá sempre ao índice 0 na matriz).
O Is Null verifica se o utilizador foi realmente encontrado. E, dependendo do resultado (True/False), o If-Else bloqueará ou interromperá o processo de negócio com uma mensagem de erro (Raise Error bloquear) ou dirigi-lo mais longe.
Verificação da palavra-passe
Nesta fase, é necessário certificar-se de que a senha de utilizador é introduzida correctamente.
E aqui, é essencial compreender que as palavras-passe não são armazenadas explicitamente na base de dados. O Bcrypt A função hasheshes, e apenas o hash resultante é armazenado na base de dados. Portanto, mesmo que assumamos que ocorrerá uma fuga de dados, os atacantes continuarão a não ser capazes de encontrar senhas de utilizador; estas são encriptadas de forma segura.
Por esta razão, não se pode simplesmente obter a palavra-passe da base de dados e compará-la com a palavra-passe introduzida. É necessário obter o hash da palavra-passe e utilizá-lo para a comparação. Para resolver este problema, a Auth: Probe Password é utilizado um bloco. Como parâmetros de entrada, toma a password introduzida pelo utilizador (password) e o hash da password armazenada na base de dados (hashed_password) e converte-a para o tipo de dados String (o To String bloco).
Dependendo do resultado, como na etapa anterior, utilizando o If-Else bloco, ou exibimos uma mensagem de erro (Raise Error, Message = Password is wrong) ou orientar o processo para a fase seguinte.
Extensão do modelo de utilizador
Para o passo seguinte, é necessário fazer uma pequena alteração no modelo do utilizador e acrescentar informação sobre o código que precisa de ser confirmado.
Em geral, o modelo User contém inicialmente campos que podem ser utilizados para esta tarefa - Confirmed, Confirmation code, Confirmation code expires at. Mas neste exemplo, vamos assumir que estes campos são utilizados apenas para o registo e verificação inicial da conta.
Para maior clareza do processo, vamos criar um modelo separado twofa (two-factor authentication), associar o modelo User a ele (relação 1-para-1, has one), e adicionar um campo - code ( tipoString ).
Preparação para o envio de emails
Para enviar e-mails com códigos de confirmação, deve-se preparar a preliminar. Uma das opções mais acessíveis é utilizar o Custom SMTP módulo, que precisa de instalar e configurar.
Ao utilizar Gmail, a maioria das definições já estão definidas por defeito, e é necessário adicionar o seu nome de utilizador e palavra-passe. Ao utilizar outros servidores de correio, seria útil se se referisse à sua documentação para obter os dados necessários.
Neste caso, poderá ter de alterar ligeiramente as definições de segurança do servidor de correio. Por exemplo, Gmail pode bloquear ligações utilizando aplicações de terceiros por defeito, e terá de remover esta restrição nas definições.
Envio de um código de verificação
Verificámos o login e a palavra-chave e concluímos todos os preparativos necessários, pelo que agora pode proceder ao envio de uma carta com um código de confirmação.
O Custom SMTP: Send Email bloco utiliza um conjunto de endereços como destino. Portanto, mesmo que seja necessário enviar uma carta para apenas um endereço, este deve ser acrescentado à matriz. Para tal, o Append Array é utilizado um bloco.
O passo seguinte consiste em gerar um código de verificação. O é utilizado. Random string bloco é adequado para isto. Enviaremos um código composto por 6 números aleatórios e faremos as configurações apropriadas. Length = 6, With 0-9 = True Todos os outros parâmetros = False.
A seguir, é necessário criar o texto da letra. Para o fazer, utilizar o Concat Strings bloco para adicionar texto explicativo ao código gerado (First = Verification code: ), converter o resultado para o tipo de dados Text (To Text bloco), e ligar o resultado ao body parâmetro do bloco de envio de correio electrónico.
Para o envio final, resta apenas especificar o assunto da carta (subject) e o remetente (from_name).
Mas não basta apenas enviar o código; ele deve também ser armazenado nos dados do utilizador. Afinal, é necessário verificar a sua correcção quando o utilizador recebe o código e o envia de volta como confirmação.
Para tal, utilizaremos o modelo twofa, que criámos prudentemente anteriormente. Se este for o primeiro envio de código, deverá criá-lo com informação sobre qual o utilizador a que pertence. Em caso de reutilização, é necessário remendar a entrada existente, indicando o seu ID e o novo código.
A etapa final da fase é utilizar o Raise Error bloco para devolver uma mensagem sobre o envio do código para o e-mail.
Verificação da relevância do código
Vale a pena cuidar da segurança adicional e proteger o código de uma enumeração banal. Seria sensato limitar o número de tentativas de entrada, a sua frequência, e o tempo de vida útil do código submetido. Não vamos analisar todos estes exemplos; os requisitos de segurança são individuais para cada projecto e podem incluir muitas condições diferentes. Limitamo-nos a verificar a relevância do código pelo seu período de validade.
Vamos utilizar o bloco Current date & time bloco para obter a hora actual. Ligue-o ao parâmetro B do Date & time difference bloco. Vamos utilizar o UpdatedAt do modelo twofa como o parâmetro A.
Como resultado, obtemos Time span - a diferença entre dois pontos de tempo. Resta apenas verificar se esta diferença excede um determinado valor seleccionado. No nosso exemplo, isto é 5 minutos, que definiremos como o valor estático B do Greater bloco.
O If-Else bloco utilizará o resultado da comparação para guiar o processo mais adiante. Se True (a diferença excede os 5 minutos), o processo voltará à etapa de envio da carta; o utilizador receberá um código actualizado. No caso de False (o código é recente e actualizado), será possível proceder à verificação deste código.
Revisão do código
A fase final da autenticação é a verificação do código recebido.
O Equal bloco deve validar que o código passado pelo utilizador corresponde ao código armazenado no modelo twofa associado ao utilizador. Se não for este o caso e o código for especificado incorrectamente (If-Else -> False), então é necessário exibir uma mensagem de erro (Raise Error, Message = Code is wrong). Se a comparação confirmar a correspondência, pode prosseguir para a fase final de autenticação.
Para o fazer, utilizamos a Auth: Authentication bloquear e obter informações sobre o utilizador com o seu código de autorização. Passamo-las para o bloco End bloqueio como resultado de uma autenticação bem sucedida.
Criação de um ponto final
O processo comercial foi criado mas ainda não está disponível para utilização. É necessário criar um ponto final que irá gerir este processo de negócio.
Uma solução razoável seria utilizar o endpoint de autenticação padrão (POST /Auth). Será suficiente para substituir o seu processo de negócio e instalar o que acabou de ser criado. Assim, a autenticação simples será desactivada, e a autenticação de dois factores será utilizada em seu lugar.
Publicação e testes
Isto completa a criação da autenticação de dois factores. É possível publicar o resultado e verificá-lo em acção. Para tal, é conveniente utilizar Swagger, ao qual se pode aceder clicando no nome do plano Deploy na secção Project API do botão Preview.
Resta apenas encontrar o ponto final desejado na lista, introduzir os dados do utilizador e iniciar a execução com o botão Execute. Se forem encontrados quaisquer erros durante os testes, voltar ao processo comercial e fazer as alterações necessárias.
