El estado de exito de /reset-password no muestra el mail de destino ni el requestId como referencia
El estado de exito de /reset-password muestra solo copy generico: 'Correo electronico enviado / Se ha enviado un enlace...'. Elazar lo verifico en el navegador; coder-mba-l-ca confirmo por lectura estatica de origin/dev que la pagina no renderiza otra cosa. NO es un problema de cache del navegador: no esta implementado. Lo que tiene que mostrar el estado de exito: 1. El mail de DESTINO tal como se envio, para que el usuario vea a donde fue y detecte un tipeo. 2. El requestId de la respuesta del POST, como referencia de transaccion citable a soporte. PROHIBIDO, y es la restriccion que fija el diseno: NUNCA exponer el token de reset ni nada derivado de el. El token es el factor de posesion (ver MOVILBA-323); mostrarlo en pantalla lo convierte en publico para cualquiera que mire el monitor. Cuidado con el mail de destino: mostrar el mail que el usuario ACABA de tipear no filtra nada -ya lo sabe-. NO mostrar ningun mail que venga del servidor ni ninguna senal de si la cuenta existe: el endpoint tiene que seguir contestando igual para un mail registrado y uno que no, o el estado de exito se vuelve un oraculo de enumeracion de cuentas. O sea el mail sale del INPUT del cliente, no de la respuesta. Distinto de MOVILBA-323, que es el redirect de proxy.ts que hace inalcanzable la pagina del link. Este es el estado de exito del formulario de pedido. Los dos tocan reset-password y no se pisan. Tests: uno que asserta que el mail mostrado es el del input y no viene del payload de respuesta, y uno que asserta que la respuesta del servidor es identica para mail existente e inexistente.
Activity
-
coder-mba-l-ca
-
Shipeado en 1fa28e4e, dev v5.5.39. Implementado por coder-mba-l-ca, auditado por audit-mba-l-cc, integrado y deployado por coder02. Lo pedido (mitad UX): el estado de exito muestra 'Correo electronico indicado: <mail>' y 'Referencia de la solicitud: <requestId>'. Lo que aparecio al implementarlo y es mas grave: POST /api/auth/reset-password contestaba TRES cuerpos distintos segun el estado de la cuenta -inexistente e inactivo devolvian 'Si el correo existe...', el envio real devolvia 'Se ha enviado un enlace a su correo'-. Mandando una direccion y leyendo el mensaje se aprendia si la cuenta existe: ORACULO DE ENUMERACION DE CUENTAS en el cuerpo. Las tres ramas devuelven ahora el mismo payload construido por una sola funcion, para que no se puedan volver a separar. El mail mostrado sale del INPUT del cliente, nunca de la respuesta; el token no se expone en ninguna forma. Cambio de coder02 sobre el diff auditado: el encabezado decia 'Correo electronico enviado', que AFIRMA un envio, mientras el cuerpo dice 'Si el correo existe...', que no. Pasa a 'Solicitud registrada'. NO CUBIERTO: el oraculo del CUERPO esta cerrado, el de TIEMPO no se midio -la rama del envio real hace mas trabajo que las otras dos-. Tampoco se ejercito la rama de rate-limit ni se abrio la pagina en un navegador.