Saltearse al contenido
PANDA — Documentación

Autenticación y permisos

Dos sistemas de login, un mismo backend de Auth

/admin/login.html expone dos formularios que usan Supabase Auth de maneras distintas:

  • Administración (email + contraseña): login estándar de Supabase Auth para usuarios con fila en usuarios_admin.
  • Acceso de socio (DNI + número de socio): PENDIENTE DE VALIDACIÓN el mecanismo exacto — no se confirmó en esta sesión si usa Supabase Auth con un email sintético, un magic link, o una validación custom vía RPC contra el padrón.

Roles y permisos

Los roles de administración están definidos en las tablas roles_admin y usuarios_admin (migración 20260626_usuarios_admin_auth.sql). Los roles verificados en producción hoy son: Presidente, Responsable de Atención al Socio, Tesorero, Profe, Directivo Disciplina, Vocal. El detalle de qué puede hacer cada uno está en Usuarios y roles.

Los permisos son JSONB por rol, con posibilidad de excepciones puntuales por usuario superpuestas al rol.

Las tres capas de validación

  1. Frontend: oculta/muestra módulos del menú según los permisos del usuario logueado. Es UX, no seguridad — no debe asumirse como control real.
  2. Worker de Cloudflare (_worker.js): para las rutas listadas en run_worker_first de wrangler.jsonc (hoy: /archivos/portal_data.json, /archivos/socios_data.json, /admin/dashboard-financiero.html, /admin/estado-resultados.html), el Worker llama a la RPC mis_permisos() antes de servir el archivo, y filtra PII de los JSON según el rol. Sin esto, esas rutas se servirían como assets estáticos sin ningún control server-side.
  3. RLS en Postgres: la última línea de defensa — cada política de RLS decide si una fila es visible/editable para el auth.uid() de la sesión, sin importar lo que hicieron las capas 1 y 2.