FactuGES_ERP/docs/prompt-auth.md
david e5e73a5a13 Refactor documentation for ERP architecture and customer invoices
- 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.
2026-08-05 13:18:03 +02:00

2.9 KiB

Prompt Auth

Base comun reutilizada: 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