US-048 — Login email + password

Detalle de la historia¶

Historia¶

Como usuario del backoffice de FleteChat, quiero iniciar sesión con mi email y contraseña, para acceder a las funciones autorizadas según mi rol.

Persona de usuario¶

Aplica a todos los usuarios del backoffice (admin, operator, price_manager). No aplica al cliente final del servicio logístico, que interactúa por WhatsApp y no tiene cuenta en el backoffice.

Contexto de negocio¶

El backoffice necesita autenticar a sus usuarios antes de habilitar cualquier acción. En v1.0 el mecanismo es email + contraseña sobre HTTPS, con política de contraseña razonable, bloqueo por intentos fallidos y sesión con timeout de inactividad. No se incluye SSO, 2FA ni integración con directorios corporativos en v1.0: son candidatos para versiones posteriores.

El login es el paso previo a todo: sin sesión válida el usuario no ve nada del backoffice ni la API responde con datos. La experiencia debe ser sobria, con mensajes que no filtren información (un intento fallido dice "credenciales inválidas" sin detallar si el email existe o la contraseña estuvo mal).

Criterios de aceptación¶

Formulario y política¶

1. La página de login pide email y contraseña sobre HTTPS. Sin HTTPS la página no se sirve.
2. El email es único por usuario (ver historia de gestión de usuarios). No distingue mayúsculas/minúsculas.
3. La contraseña cumple la política mínima declarada en PR-187. Al crear o cambiar contraseña (ver historia de gestión de usuarios y recuperación más abajo) el sistema valida y rechaza las que no cumplen.

Autenticación¶

1. Credenciales válidas → sesión iniciada; el usuario es dirigido a la página de inicio de su rol.
2. Credenciales inválidas → mensaje genérico "credenciales inválidas" sin revelar si el email existe o si la contraseña fue incorrecta.
3. Tras N intentos fallidos consecutivos para un mismo email (ver PR-188), la cuenta queda bloqueada por una ventana configurable; mensaje al usuario pide esperar y contactar al admin si persiste. El admin puede desbloquearla desde la gestión de usuarios.
4. Los intentos fallidos quedan registrados en el audit log con email, IP, user-agent y timestamp.

Sesión¶

1. La sesión establecida tiene timeout por inactividad configurable (ver PR-189). Tras el timeout, al volver a operar el usuario es redirigido a login y pierde estado no guardado.
2. El logout explícito es accionable desde cualquier página del backoffice; invalida la sesión del lado servidor.

Recuperación de contraseña¶

1. Desde la página de login hay un enlace "Olvidé mi contraseña". El usuario ingresa su email; si existe una cuenta con ese email, el sistema envía un correo con un enlace firmado y ventana corta de validez (valor configurable) para definir una nueva contraseña. Si el email no existe, el sistema responde con el mismo mensaje genérico ("si su email está registrado recibirá un correo") para no filtrar existencia.
2. El enlace de recuperación es de un solo uso; al cambiar la contraseña, cualquier enlace anterior queda invalidado.

Edge cases¶

• Usuario intenta login estando bloqueado por intentos fallidos. El sistema rechaza con mensaje que indica bloqueo temporal sin revelar detalles. El audit log registra el intento.
• Usuario desactivado por el admin intenta login. Rechazado con el mismo mensaje genérico de credenciales inválidas (para no filtrar estado de cuenta). El audit log registra el intento con la razón "cuenta desactivada" para investigación interna.
• Sesión activa y admin cambia el rol del usuario. La sesión actual conserva el rol anterior hasta logout o expiración (ver PR-186 de US-047). El admin puede forzar el cierre de sesión desde la gestión de usuarios.
• Usuario solicita recuperación de contraseña varias veces seguidas. Cada solicitud invalida enlaces anteriores; el sistema limita la cantidad de solicitudes por ventana de tiempo (rate limit configurable) para prevenir abuso del correo.
• Usuario completa el flujo de recuperación con un enlace vencido. La página muestra "enlace vencido" y lo redirige a solicitar uno nuevo.

Tamaño, prioridad y tipo¶

• Tamaño: M
• Prioridad: P0 — sin login no hay backoffice accesible.
• Tipo: feature

Premisas¶

La historia está redactada bajo las siguientes premisas. Si alguna cambia, la historia debe revisarse y ajustarse en consecuencia. Todas deben ser confirmadas por el cliente antes de cerrar la historia.

• PR-187 — Política de contraseña. Las contraseñas deben tener mínimo 10 caracteres, al menos una mayúscula, una minúscula, un número y un carácter especial. Configurable por FleteChat desde parámetros globales (ver US-046).
• PR-188 — Bloqueo por intentos fallidos. Tras 5 intentos fallidos consecutivos sobre el mismo email, la cuenta se bloquea por 15 minutos (valores configurables desde parámetros globales). El admin puede desbloquear antes desde la gestión de usuarios.
• PR-189 — Timeout de sesión por inactividad. La sesión expira tras 30 minutos de inactividad por defecto (configurable desde parámetros globales). No hay "recordarme": todas las sesiones caducan.

Refinamiento y Definition of Ready¶

Notas¶

Checklist¶

• ✅ Historia escrita en formato Como / Quiero / Para
• ✅ Persona de usuario identificada
• ✅ Contexto de negocio documentado
• ✅ Criterios de aceptación observables y pass/fail
• ✅ Edge cases relevantes listados
• ✅ Tamaño y prioridad asignados
• ⬜ Premisas PR-187 a PR-189 confirmadas por el cliente
• ⬜ Reglas de negocio aplicables aprobadas
• ⬜ Requerimientos funcionales aplicables aprobados
• ⬜ Historia aprobada formalmente por el cliente