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). Cada inicio de sesión correcto se anota en LoginAudit (usuario, proveedor, sistema operativo y navegador). Lo consulta solo un administrador en /auditoria. El detalle está en Auditoría de acceso. Salud, auditoría, la documentación de la API y la edición de textos legales están en el grupo Configuración del panel, solo para ADMIN. Los textos se describen en Textos legales.

​
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.
El prestador puede indicar un precio referencial opcional al registrarse (priceFrom en COP y priceUnit: hora, servicio o dia). Lo cambia después en /dashboard/perfil con PATCH /api/me/price. Sin ficha de camello, ese endpoint responde 409. No es un cobro de la plataforma.

​
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.
Los dos endpoints de búsqueda son públicos, pero si hay sesión leen del servidor, con getServerSession, la ciudad y el barrio guardados en el perfil del usuario: esa ubicación nunca viaja desde el cliente como dato de confianza. * Según visibilidad del Job (dueño, camello asignado o admin). En accept, reject y complete la regla es más estricta: ver †. † 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. ‡ schedule lo llama el cliente dueño del trabajo. Un admin que no sea ese cliente recibe 404. POST /api/cron/appointment-reminders no usa sesión. Exige Authorization: Bearer con CRON_SECRET.