Middleware - Portal de Clientes

Middleware de procesamiento de requests del portal.

Middleware Disponibles

PortalAuthMiddleware

Responsabilidad: Validar JWT, resolver tenant y schema, establecer conexion a base de datos.

Flujo:

1. Extraer JWT del header Authorization: Bearer
2. Validar firma y expiracion del token
3. Extraer tenant_id y sucursal_id del payload
4. Validar tenant en ini.sistema
5. Resolver base de datos y schema
6. Establecer conexion via ConnectionMiddleware
7. Inyectar portal_user_context y tenant_context en el request

Rutas publicas (sin JWT):

• POST /portal/auth/register — Auto-registro
• POST /portal/auth/login — Login con password
• POST /portal/auth/forgot-password — Solicitar codigo de reset
• POST /portal/auth/reset-password — Resetear password con codigo

Estas rutas reciben tenant_id y sucursal_id desde el body o headers del request (no del JWT).

ConnectionMiddleware (Reutilizado)

Ya existe en el backend. No requiere modificaciones.

Adaptacion:

• Recibe tenant_context del PortalAuthMiddleware
• Configura ConnectionManager con database y schema del tenant
• Funciona identico al flujo del Admin UI

Flujo de Middleware

flowchart TD
    A[Request] --> B[PortalAuthMiddleware]
    B --> C{Ruta publica?}
    C -->|Si| D[Extraer tenant_id/sucursal_id del body/headers]
    C -->|No| E[Extraer y validar JWT]
    E --> F[Extraer tenant_id + sucursal_id del JWT]
    D --> G[Validar tenant en ini.sistema]
    F --> G
    G --> H[Resolver database + schema]
    H --> I[ConnectionMiddleware]
    I --> J[Controller]

Diferencias con el Diseno Anterior

Aspecto	Diseno anterior	Diseno actual
Resolucion de tenant	Por dominio (tenant_domains tabla)	Por tenant_id en JWT o request body
Autenticacion	Session PHP o JWT ligero	JWT con password (mismo patron que Admin UI)
Tabla de dominios	tenant_domains en DB ini	No existe. Configuracion en .env del Docker
Resolucion de DB	Dominio → tenant_domains.database	tenant_id → ini.sistema → DB
Resolucion de schema	tenant_domains.schema_default	sucursal_id → schema

Multi-Tenant Context

El middleware inyecta dos contextos en cada request:

tenant_context (siempre presente):

• tenant_id: ID del tenant
• sucursal_id: ID de la sucursal
• database: Nombre de la base de datos
• schema: Schema resuelto

portal_user_context (solo rutas protegidas):

• portal_user_id: UUID del usuario del portal
• cliente_id: ID del cliente en ordcon

Ver tambien

• PortalAuthMiddleware
• API Endpoints
• Security