Uecko/Uecko_ERP
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
3e5791afdb
Uecko_ERP/docs/architecture/README.md

3.7 KiB
Raw Blame History

ERP Backend · Identity/Auth Migration Notes

Propósito

Este documento consolida las decisiones de arquitectura y el estado de migración del backend ERP desde el módulo legacy auth hacia el nuevo módulo identity.

Debe usarse como referencia para futuros incrementos relacionados con:

  • autenticación
  • sesión
  • contexto tenant/company
  • registro de usuarios
  • roles y permisos
  • autorización
  • login frontend
  • retirada progresiva de modules/auth

Estado actual resumido

El backend ya dispone de un módulo identity registrado en servidor y con endpoints de autenticación funcionales:

POST /identity/auth/login
POST /identity/auth/refresh
POST /identity/auth/logout
GET  /identity/auth/session

El módulo identity expone builders genéricos desde @erp/identity/api:

requireIdentityAuthenticated(params: StartParams): RequestHandler[];
requireIdentityTenant(params: StartParams): RequestHandler[];

Uso esperado en routers tenant-scoped:

import { requireIdentityTenant } from "@erp/identity/api";

router.use(...requireIdentityTenant(params));

Uso esperado en routers que solo requieren usuario autenticado:

import { requireIdentityAuthenticated } from "@erp/identity/api";

router.use(...requireIdentityAuthenticated(params));

Módulos backend migrados a identity

Ya no usan @erp/auth/api ni mockUser:

  • modules/catalogs
  • modules/customers
  • modules/customer-invoices
  • modules/factuges

Consumidores legacy pendientes

Backend pendiente explícitamente:

  • modules/supplier/src/api/infrastructure/express/suppliers.routes.ts

Frontend todavía usa cliente legacy:

  • apps/web/src/register-modules.tsx
  • apps/web/src/app.tsx

Por tanto, modules/auth no puede retirarse todavía.

Regla de arquitectura vigente

Los módulos funcionales no deben importar ni recomponer internals de identity.

No usar en módulos consumidores:

IdentityInternalDeps;
authenticateUserDependencies;
getInternal("identity");

No crear helpers de auth por módulo como patrón final:

catalogs-auth-middlewares.ts
customers-auth-middlewares.ts
...

El middleware genérico pertenece a identity.

Separación de responsabilidades

Authentication

Responde a:

  • quién es el usuario
  • si el token es válido
  • si la cuenta puede autenticarse

Tenant context

Responde a:

  • qué empresa activa se está usando en la request
  • actualmente se resuelve por header X-Company-Id

Authorization

Responderá a:

  • qué permisos efectivos tiene el usuario dentro de la empresa

Todavía no está implementado en modo completo.

Document context

Datos como companySlug, templates, certificados o metadatos de generación documental no pertenecen al middleware de autenticación.

No añadir a identity auth:

  • companySlug
  • X-Company-Slug
  • companySlug en access token

Si un flujo documental necesita companySlug, debe resolverse mediante un servicio específico de empresa/documentos.

Roadmap corto recomendado

  1. Crear pantalla de login en Frontend ERP contra /identity/auth/login.
  2. Mantener supplier temporalmente en legacy si así se decide.
  3. Implementar refresh automático en frontend.
  4. Implementar selección de empresa y uso de X-Company-Id.
  5. Implementar persistencia y validación real de CompanyMembership.
  6. Implementar resolución de permisos efectivos.
  7. Migrar supplier cuando se decida.
  8. Retirar backend legacy de @erp/auth/api.
  9. Migrar o retirar @erp/auth/client.

Documentos relacionados