Closed delgadomatias closed 2 months ago
Estuve pensando en usar otro tipo en el activationToken, algo que tenga una fecha de caducidad. Ya que en el caso que el usuario haya activado su cuenta, vuelva al mail y vuelva a ingresar, si bien la aplicación falla y muestra el mensaje de error correspondiente, se hace una query a la base de datos que creo se podría evitar. Si el token está expirado, entonces retornaríamos inmediatamente.
El código lo veo bastante bien más allá del comentario que dejo, pero se me generan algunas inquietudes
- Que pasa si por algun error no le llega el mail al usuario? Habría que tener una lógica de reenvío de mail donde el usuario, solo con saber su usuario, nosotros le podemos reenviar el token. Esto lo podemos hacer en otro MR para no agrandar más este.
- Qué hacemos si el usuario por alguna razón ingresa al link de activación una vez que su cuenta ya esté activada? Deberíamos devolver un mensaje de error o simplemente lo dejamos pasar como que ya está activada?
- Coincido con que el token debería tener un tiempo de expiración, para eso podemos agregar en la tabla usuario un "CREATED_AT" (se supone que coincide con el tiempo en que se creó el token) y cuando se quiera activar la cuenta, podemos verificar la fecha actual contra esa fecha de CREATED_AT, pero ahora pasa lo siguiente, ¿qué hacemos si el token expiró, generamos otro? ¿Hace falta que tengamos este mecanismo de seguridad solo para activar su cuenta?
Bien, para lo primero entonces asumís que se podría crear una cuenta pero no enviar el mail, caso contrario a lo que tengo en el código ya que lanzo la excepción cuando el envío falla lo cual no me permite guardar la cuenta. Podríamos hacer que, se cree la cuenta independientemente del envío del email y darle la posibilidad al usuario de que vuelva a pedir el envío.
Para lo segundo, esta que, si se ingresa al enlace de activación y la cuenta ya estaba activada, tira un mensaje de error.
Para lo ultimo, quizás este de mas hacer tanto problema para una simple activación, como el equipo decida.
@delgadomatias
Sí, la cuenta debería poder crearse más allá de si se envía el correo o no, pero lo podemos dejar para otra user story / MR
Se implementó el envío de un mail de confirmación para activar la cuenta de un usuario. Decidí implementar el UserController con el endpoint
/api/v1/users/{userId}/activate
porque me hacia mas sentido relacionarlo con la entidad usuario.Ahora bien, el flujo es el siguiente:
Funcionamiento ideal
Muestra del error
Me gustaría que todos mencionen que ven mal para un posible cambio o algún funcionamiento que vean que deba ser distinto.
Actualización
El enlace del mail redirige al frontend y le envía unos datos por parámetros en la URL, estos son el token de activación y el id del usuario correspondiente. Con esta información, se puede hacer la peticion POST pasando el token como body. De esta forma, el backend puede validar si el token le corresponde a ese usuario y entonces activar la cuenta.