Authentication

Surflink uses Supabase Auth for user authentication, with server-side session management via the @supabase/ssr package.

Auth Flow

1. Sign Up / Sign In -- Users authenticate via email/password or OAuth through the /login and /signup pages
2. Session Management -- Supabase stores the session in HTTP cookies, managed by the SSR middleware
3. Token Refresh -- The middleware automatically refreshes the auth token on every request
4. Profile Creation -- On first OAuth callback, a coaches profile row is auto-created for the authenticated user

Middleware

The auth middleware (src/middleware.js) runs on every request except static assets and the video stream endpoint. It performs these tasks:

1. Creates a Supabase SSR client with cookie-based session management
2. Refreshes the auth token via supabase.auth.getUser()
3. Cleans up stale chunked cookies -- Supabase SSR creates chunked cookies (sb-xxx-auth-token.0, .1, .2, etc.) that can accumulate and cause 431 (Header Too Large) errors
4. Enforces route protection -- Unauthenticated users are redirected to /login on protected routes
5. Redirects authenticated users away from /login and /signup to /dashboard

Public Routes

These routes are accessible without authentication:

Supabase Clients

The project maintains three Supabase client configurations:

Role-Based Routing

The AuthProvider context exposes the current user, coach profile, and loading state. Components use the useAuth() hook to access this context.

OAuth Callback

The OAuth callback handler at /auth/callback exchanges the authorization code for a session, then checks if a coaches row exists for the authenticated user. If not, it creates one automatically with the user's email and metadata.