david
e5e73a5a13
- Updated general requirements document to clarify its historical context and remove outdated technical details. - Revised template documentation to serve as a base for writing prompts, emphasizing its auxiliary nature. - Enhanced architecture documentation with clear distinctions between canonical and complementary documents. - Added a new document for backend prompt base to centralize common context for backend prompts. - Created a dedicated README for customer invoices, organizing current contracts, operational support, and historical context. - Improved clarity and structure in various customer invoice documents, consolidating operational semantics and referencing canonical sources.
78 lines
2.9 KiB
Markdown
78 lines
2.9 KiB
Markdown
# Prompt Auth
|
|
|
|
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`
|