fix(auth): comprobar el rol de la sesion en todas las rutas #7
Reference in New Issue
Block a user
Delete Branch "fix/verificar-rol-de-sesion"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
El agujero
Las tres sesiones (
admin,cliente,jefe) se firman con el mismo secreto yverificarSesionsolo validaba la firma, nunca elroleque viaja en el token. Un token de cualquier rol, puesto en la cookie de otro, pasaba la verificacion.Medido contra la app antes del cambio:
cliente_session→/api/cliente/autoscliente_session→/cliente/dashboardNo se filtraban datos ajenos, porque todas las consultas se filtran por el
subdel token y el id de un admin no existe como cliente. Pero los endpoints quedaban alcanzables, y bastaba una consulta futura menos cuidadosa para que si importara.El cambio
verificarSesionpasan el rol esperado.jwtVerifysin mirar el rol: ahora tambien lo comprueba.sesion.role !== "jefe"de las rutas de jefe, que quedaron redundantes.Matriz probada contra la app
Con tokens firmados a mano con el secreto local, uno por rol:
/api/cliente/perfil200, jefe →/api/jefe/servicios200, admin →/api/admin/servicios200./cliente/dashboard307, cliente→/admin/dashboard307, cliente→/cliente/dashboard200.tsc,lint,test:bot,test:envioynext build: limpios.🤖 Generated with Claude Code
Inline review
@@ -6,3 +6,2 @@export async function PATCH(req: NextRequest, { params }: { params: Promise<{ id: string }> }) {const sesion = await verificarSesion("jefe_session");if (!sesion || sesion.role !== "jefe")const sesion = await verificarSesion("jefe_session", "jefe");Se eliminó la verificación explícita
sesion.role !== 'jefe'confiando en queverificarSesionvalide el rol. Está bien si la función lo hace, pero siverificarSesionsolo chequea la firma del token y no el rol, un admin o cliente con cookie de jefe podría acceder. ¿La función valida el rol internamente?#ai-review-inline
@@ -6,1 +6,3 @@async function verifyCookie(req: NextRequest, cookieName: string) {// Las tres sesiones se firman con el mismo secreto, así que además de la firma hay// que mirar el rol: si no, un token de jefe en la cookie del cliente pasa.async function verifyCookie(req: NextRequest, cookieName: string, rol: "admin" | "cliente" | "jefe") {La función
verifyCookieahora requiere el parámetrorol, peroverificarSesionensrc/lib/auth-admin.tsno aparece en el diff. Si no se actualizó ahí para aceptar y validar el segundo argumento, todas las rutas API fallarán en runtime.#ai-review-inline
@@ -10,2 +12,2 @@await jwtVerify(token, SECRET);return true;const { payload } = await jwtVerify(token, SECRET);return (payload as { role?: string }).role === rol;El cast
(payload as { role?: string })asume que el JWT siempre tiene un camporole. ¿Confirmaste que los tokens generados al loguear (admin, jefe, cliente) incluyen ese claim? Si no, la validación siempre fallará y nadie podrá acceder.#ai-review-inline
Inline review
Inline review
Inline review
@@ -6,3 +6,2 @@export async function GET() {const sesion = await verificarSesion("jefe_session");if (!sesion || sesion.role !== "jefe")const sesion = await verificarSesion("jefe_session", "jefe");Mismo caso: se quitó el check de rol explícito. Si
verificarSesionno valida el rol, esto abre acceso indebido. Verificá la implementación enauth-admin.ts.#ai-review-inline
@@ -5,3 +5,2 @@export async function GET(req: NextRequest) {const sesion = await verificarSesion("jefe_session");if (!sesion || sesion.role !== "jefe")const sesion = await verificarSesion("jefe_session", "jefe");Igual que arriba: se confía en
verificarSesion('jefe_session', 'jefe')para validar rol. Confirmá que la función lanza 401 si el rol no coincide, no solo si el token es inválido.#ai-review-inline
Inline review
Qué cambia
Se agrega validación de rol en la verificación de sesión:
verificarSesionyverifyCookieahora reciben el rol esperado ("admin" | "cliente" | "jefe") y validan que el payload del JWT coincida. Antes el middleware solo verificaba la firma, permitiendo que un token de un rol accediera a rutas de otro si compartía nombre de cookie.Riesgos
Cambio de contrato en
verificarSesion(parámetro nuevo obligatorio). Si queda alguna llamada sin el segundo argumento, romperá en runtime. El middleware ahora rechaza tokens con rol incorrecto: antes un token de jefe encliente_sessionpasaba, ahora no.Antes de aprobar
Buscar llamadas a
verificarSesionsin el segundo parámetro (grep -r "verificarSesion(" --include="*.ts"). Probar login y acceso a rutas de cada rol (admin, cliente, jefe) y confirmar que un token de un rol no accede a rutas de otro. Verificar quepnpm checkpase (tipos de TypeScript).#ai-review-summary