feat(auth): implementar fluxo completo de recuperação e redefinição d… #259
Conversation
| @@ -0,0 +1,15 @@ | |||
| import { Knex } from 'knex'; | |||
There was a problem hiding this comment.
O banco de dados utiliza um padrão de nomemclatura em português, modifique para seguir o padrão, por favor.
| }); | ||
| } | ||
|
|
||
| export async function down(knex: Knex): Promise<void> { |
There was a problem hiding this comment.
O sistema de migração existente não tem a possibilidade de fazer rollback, a função down não precisa existir.
| isEmpty: false, | ||
| errorMessage: 'O token é obrigatório.', | ||
| }, | ||
| novaSenha: { |
There was a problem hiding this comment.
O sistema usa snake_case como padrão de nomenclatura, por favor modifique para seguir o padrão.
src/routes/usuarios.js
Outdated
| * '500': | ||
| * $ref: '#/components/responses/InternalServerError' | ||
| */ | ||
| app.route('/usuarios/solicitar-reset-senha') |
There was a problem hiding this comment.
O que acha de solicitar-redefinicao-senha? Para não misturar português e inglês.
|
|
||
| await Usuario.update( | ||
| { reset_token: token, reset_token_expiration: dataExpiracao }, | ||
| { where: { id: user.id } } |
There was a problem hiding this comment.
Na rota que você altera a senha você verifica se o usuário está ativo ou não. Acho que faz sentido verificar aqui na hora de gerar o token também, pois o usuário vai ser capaz de enviar o token mas não será capaz de alterar a senha.
|
|
||
| if (!user) { | ||
| return response.status(400).json({ | ||
| sucesso: false, |
There was a problem hiding this comment.
Este parâmetro é redundante, o código 400 já indica que a requisição não deu sucesso.
| mensagem: 'Senha redefinida com sucesso.', | ||
| }); | ||
| } catch (err) { | ||
| // ✅ Remove console.error para passar no lint |
| if (user) { | ||
| const token = geraTokenResetSenha(user.id); | ||
| const dataExpiracao = new Date(); | ||
| dataExpiracao.setMinutes(dataExpiracao.getMinutes() + 45); |
There was a problem hiding this comment.
@luscas18 tem algumas que gostaria de entender, discutir contigo:
- colocar o id do usuário dentro do token eu diria que é um pouco perigoso, pois o conteúdo do token não é criptografado, alguém com o email de um usuário pode obter o id do usuário e explorar posssíveis vulnerabilidades no sistema. Você pode usar um uuid randômico que é único para cada solicitação.
- por que você criou um jwt como token? Não poderia ser simplesmente um uuid aleatório que é armazenado no banco com data de expiração?
- ainda sobre a data de expiração, se você optar por usar um jwt, ele já possui expiração embutida, por que você guardar a data de expiração no banco de dados também? Não é só usar a data de expiração do token?
| { where: { id: user.id } } | ||
| ); | ||
|
|
||
| return response.status(200).json({ |
There was a problem hiding this comment.
Aqui você pode substituir por 204, não precisa retornar nada dizendo que de deu certo, o código http já é suficiente.
2 participants
No arquivo .env adicionar os acessos da Nodemailer.
⚙️ Passo a passo
Acesse https://myaccount.google.com/security
Ative Verificação em duas etapas (2FA) se ainda não estiver ativada.
Depois de ativada, acesse:
👉 https://myaccount.google.com/apppasswords
Escolha:
Aplicativo → “Outro (Nome personalizado)” → digite “HCF API”
Dispositivo → “Computador”
O Google mostrará uma senha de 16 caracteres — guarde-a.
URL_PAINEL é a url do painel para anexar ao token para o usuário acessar.