[UDT-005/006] Crear ProtectedRoute reutilizable con rol-check en frontend #5

New Issue

dmolinari · 2026-04-15T14:19:43Z

dmolinari commented

2026-04-15 14:19:43 +00:00

Origen: UDT-003 (PR #4) — detectado al proteger /usuarios/nuevo por rol admin.

Contexto actual

En src/web/src/features/users/pages/CreateUserPage.tsx el guard de rol se hace inline: early return + navigate('/') si user.rol !== 'admin'.
Funciona para UDT-003 pero no es reutilizable.

Qué hay que hacer cuando se aterrice RBAC (UDT-005/006)

Crear un componente src/web/src/components/auth/ProtectedRoute.tsx que acepte una lista de roles y/o permisos requeridos (requiredRoles?: string[], requiredPermissions?: string[]).
Integrarlo en router.tsx como wrapper de las rutas protegidas.
Reemplazar el guard inline de CreateUserPage.tsx por el nuevo ProtectedRoute.
Para permisos granulares, consumir el hook usePermission / CanPerform que se definirá en UDT-006.

Acceptance criteria

ProtectedRoute renderiza children sólo si el usuario cumple roles/permisos; si no, redirect a / o 403.
Test unit cubre: sin auth, rol incorrecto, rol correcto, permisos granulares.
CreateUserPage deja de tener guard inline y usa ProtectedRoute.
Todas las rutas protegidas del módulo Auth pasan por ProtectedRoute.

Archivo a consultar al retomar: engram sdd/udt-003-registro-usuarios/archive-report (deuda documentada).

**Origen**: UDT-003 (PR #4) — detectado al proteger `/usuarios/nuevo` por rol admin. **Contexto actual** - En `src/web/src/features/users/pages/CreateUserPage.tsx` el guard de rol se hace inline: early return + `navigate('/')` si `user.rol !== 'admin'`. - Funciona para UDT-003 pero no es reutilizable. **Qué hay que hacer cuando se aterrice RBAC (UDT-005/006)** - Crear un componente `src/web/src/components/auth/ProtectedRoute.tsx` que acepte una lista de roles y/o permisos requeridos (`requiredRoles?: string[]`, `requiredPermissions?: string[]`). - Integrarlo en `router.tsx` como wrapper de las rutas protegidas. - Reemplazar el guard inline de `CreateUserPage.tsx` por el nuevo `ProtectedRoute`. - Para permisos granulares, consumir el hook `usePermission` / `CanPerform` que se definirá en UDT-006. **Acceptance criteria** - [ ] `ProtectedRoute` renderiza children sólo si el usuario cumple roles/permisos; si no, redirect a `/` o 403. - [ ] Test unit cubre: sin auth, rol incorrecto, rol correcto, permisos granulares. - [ ] `CreateUserPage` deja de tener guard inline y usa `ProtectedRoute`. - [ ] Todas las rutas protegidas del módulo Auth pasan por `ProtectedRoute`. **Archivo a consultar al retomar**: engram `sdd/udt-003-registro-usuarios/archive-report` (deuda documentada).

dmolinari added the followup label 2026-04-15 14:19:43 +00:00

dmolinari referenced this issue

2026-04-15 14:23:48 +00:00

UDT-003: Registro de Usuarios (admin-only) + fix JWT claim mapping #4

dmolinari commented

2026-04-15 18:14:32 +00:00

Reasignado formalmente a UDT-006 (Middleware de Autorización). En UDT-005 las rutas /admin/permisos usan el ProtectedRoute actual (auth-only). El componente granular con requiredPermissions requiere que el enforcement backend exista, cosa que recién llega con UDT-006.

Reasignado formalmente a **UDT-006 (Middleware de Autorización)**. En UDT-005 las rutas `/admin/permisos` usan el `ProtectedRoute` actual (auth-only). El componente granular con `requiredPermissions` requiere que el enforcement backend exista, cosa que recién llega con UDT-006.

dmolinari referenced this issue

2026-04-15 18:58:34 +00:00

UDT-005: Gestión de Permisos (RBAC) — catálogo + asignación rol↔permisos #9

dmolinari referenced a pull request that will close this issue

2026-04-15 19:52:44 +00:00

UDT-006: Middleware de Autorización (RBAC enforcement) #10

dmolinari closed this issue

2026-04-15 20:15:19 +00:00

Sign in to join this conversation.