David
dac22372b9
- Archived historical documents for DTO design and naming conventions. - Added normative documentation for HTTP request flow and module boundaries. - Introduced testing guidelines for backend layers. - Updated onboarding module documentation and clarified onboarding requirements. - Deprecated backend prompt base and prompt auth documents. - Adjusted paths in testing documentation for consistency.
80 lines
3.1 KiB
Markdown
80 lines
3.1 KiB
Markdown
# HISTÓRICO/AUXILIAR — Prompt Auth
|
|
|
|
> Este prompt no establece reglas transversales. Para arquitectura vigente, consultar [arquitectura normativa](./architecture/README.md).
|
|
|
|
Base comun reutilizada: [`backend-prompt-base.md`](./backend-prompt-base.md)
|
|
|
|
Este prompt añade solo las reglas especificas de autenticacion sobre esa base.
|
|
|
|
## Contexto especifico
|
|
|
|
La API maneja autenticacion con `PassportJS`, soporte para `JWT` y `LocalStrategy`, gestion segura de contrasenas con `bcrypt` y transformacion de respuestas con DTOs.
|
|
|
|
## Gestion de dependencias
|
|
|
|
- `AuthService` debe crearse con un factory como `createAuthService()`
|
|
- `AuthService` depende de `IAuthenticatedUserRepository`, `ITransactionManager` y `IAuthProvider`
|
|
|
|
## Autenticacion con `PassportJS`
|
|
|
|
- `PassportAuthProvider` maneja `JWTStrategy` y `LocalStrategy`
|
|
- `validateUser()` verifica credenciales con `LocalStrategy`
|
|
- usar `bcrypt` para cifrar contrasenas antes de almacenarlas
|
|
- `PasswordHash.create()` valida la fuerza de la contrasena antes de cifrarla
|
|
- `bcrypt.compare()` valida la contrasena al hacer login
|
|
- las contrasenas nunca deben almacenarse en texto plano
|
|
|
|
## Gestion de errores
|
|
|
|
- `ExpressController` debe devolver errores con `ApiError`
|
|
- `RegisterController` y `LoginController` deben mapear errores a `409`, `401` o `500` segun contrato
|
|
- capturar errores de Sequelize relevantes en repositorios
|
|
- personalizar errores de unicidad mediante `errorMapper`
|
|
|
|
## Flujo de `/register`
|
|
|
|
1. Request llega a `RegisterController`
|
|
2. valida `email`, `username` y `password` como Value Objects
|
|
3. llama a `AuthService.registerUser()`
|
|
4. `AuthService` evita usuarios duplicados con `validateUser()`
|
|
5. si el usuario es nuevo, cifra la contrasena con `bcrypt.hash()`
|
|
6. persiste con `AuthenticatedUserRepository.create()`
|
|
7. genera `accessToken` y `refreshToken`
|
|
8. responde con tokens y `userId`
|
|
|
|
## Flujo de `/login`
|
|
|
|
1. Request llega a `LoginController`
|
|
2. llama a `AuthService.loginUser()` con `email` y `password`
|
|
3. busca el usuario en `AuthenticatedUserRepository.findUserByEmail()`
|
|
4. compara contrasenas con `bcrypt.compare()`
|
|
5. si la contrasena es correcta, genera tokens
|
|
6. devuelve los tokens en la response
|
|
|
|
## Transformacion de respuestas
|
|
|
|
- los controladores transforman antes de responder
|
|
- usar `AuthResponsePresenter` para mapear dominio a `AuthResponseDTO`
|
|
- inyectar presenters en controllers cuando ayude a desacoplar
|
|
|
|
## Seguridad y mejores practicas
|
|
|
|
- usar `TransactionManager.complete()` para manejar transacciones
|
|
- evitar acoplamientos directos entre servicios y repositorios
|
|
- usar `bcrypt` con `SALT_ROUNDS=12` configurable en `.env`
|
|
- si ocurre un error en BD, `rollback()` debe ejecutarse automaticamente
|
|
|
|
## Solicitudes tipicas
|
|
|
|
- generar codigo cumpliendo estas reglas
|
|
- revisar codigo y detectar violaciones de SOLID o DDD
|
|
- optimizar `AuthService` para seguridad y escalabilidad
|
|
- implementar `/refresh`
|
|
- escribir pruebas unitarias y de integracion para `registerUser()` y `loginUser()`
|
|
|
|
## Restricciones
|
|
|
|
- no acoplar dependencias directamente
|
|
- no usar Sequelize directamente en servicios
|
|
- usar interfaces como `IAuthProvider` e `ITransactionManager`
|