Skip to main content

NextAuth

src/auth.ts exporta authOptions: NextAuth v4, estrategia de sesión JWT, adapter de Prisma. El provider de Google solo se registra si AUTH_GOOGLE_ID/AUTH_GOOGLE_SECRET están presentes en el entorno. El rol del usuario viaja en el JWT y se refleja en session.user.role; las ampliaciones de tipo de NextAuth (para que role exista en Session y en JWT) están en src/types/next-auth.d.ts. En servidor, la sesión se resuelve con getServerSession(authOptions).

Roles

CamellApp tiene tres roles:
  • ADMIN: administra usuarios, servicios, camellos y asigna trabajos.
  • CAMELLOS: el prestador de servicios.
  • CLIENTES: el usuario final; es el rol por defecto al registrarse.

Login con Google

El botón oficial de Google Identity Services (GIS) y el One Tap (con acceso automático) envían un JWT a NextAuth mediante un provider de credenciales dedicado. El servidor verifica ese token con AUTH_GOOGLE_ID y:
  • crea un usuario CLIENTES si el email no existe todavía, o
  • enlaza la cuenta de Google a un usuario existente si ya hay uno con ese correo.
Como respaldo existe el flujo OAuth clásico por redirección. Al cerrar sesión se llama google.accounts.id.disableAutoSelect() para evitar que el One Tap vuelva a iniciar sesión automáticamente en el siguiente visitante.

Matriz de permisos

SI indica acceso permitido; NO, acceso denegado. El asterisco (*) se explica en la nota al pie de la tabla.
* Según visibilidad del Job (dueño, camello asignado o admin). † No es por el rol ADMIN: aceptar, rechazar y completar comprueban identidad respecto al Job (ser el camello asignado, o además el cliente dueño en el caso de completar) — no el rol de sesión. Un ADMIN que no sea ninguna de esas partes recibe 404. Si ese mismo usuario ADMIN también tiene esa identidad, actúa por ella, no por su rol: el camello asignado puede aceptar, rechazar o completar; el dueño (cliente) puede completar. Es distinto de cancel, que sí tiene un bypass explícito por rol: ahí ADMIN puede siempre, sin depender de ser dueño ni camello.