Authentication Patterns

// lib/auth.ts
import { cookies } from 'next/headers'
import { cache } from 'react'

export const getSession = cache(async () => {
  const token = (await cookies()).get('session')?.value
  if (!token) return null
  try {
    return await verifySession(token)          // JWT verify, or a DB lookup
  } catch {
    return null
  }
})

export async function requireUser() {
  const session = await getSession()
  if (!session) redirect('/login')             // throws
  return session.user
}

// A page — no useEffect, no isLoading, no flash
export default async function DashboardPage() {
  const user = await requireUser()
  const stats = await getStats(user.id)
  return <Dashboard user={user} stats={stats} />
}

// cache() means calling getSession in the layout, the page and three
// components costs one verification per request.

// The client still needs the user for interactive bits — pass it down
// as a prop rather than fetching it again:
<UserMenu user={{ id: user.id, name: user.name }} />
// and select the fields, because those props are visible in the HTML.

'use server'
export async function login(prevState, formData: FormData) {
  const parsed = LoginSchema.safeParse(Object.fromEntries(formData))
  if (!parsed.success) return { error: 'Check your details' }

  const user = await verifyCredentials(parsed.data)
  if (!user) return { error: 'Incorrect email or password' }
  // Deliberately the same message for both cases — a distinct
  // "no such user" tells an attacker which emails are registered.

  const token = await createSession(user.id)
  ;(await cookies()).set('session', token, {
    httpOnly: true,                 // JavaScript cannot read it
    secure: process.env.NODE_ENV === 'production',
    sameSite: 'lax',                // blocks cross-site POST (CSRF)
    path: '/',
    maxAge: 60 * 60 * 12,
  })
  redirect('/dashboard')
}

'use server'
export async function logout() {
  const token = (await cookies()).get('session')?.value
  if (token) await revokeSession(token)        // server-side revocation
  ;(await cookies()).delete('session')
  redirect('/login')
}

// Cookies can only be set in a server action or a route handler —
// not in a server component during render, because the response has
// already begun. That constraint shapes where auth logic lives.

// FastAPI owns the session; Next renders. Two workable designs:

// A. The browser talks to the API for auth, and the cookie is
//    same-site (api.aicancode.org). Next forwards it when rendering:
const res = await fetch(`${process.env.API_URL}/me`, {
  headers: { cookie: (await cookies()).toString() },
  cache: 'no-store',
})
// Simple, one source of truth, and the token never touches JS.

// B. Next owns the session and calls the API with a service token.
//    Better isolation, more moving parts, and the API can no longer
//    identify the user on its own.

// Libraries: Auth.js (NextAuth) and Clerk both work well when Next
// owns auth. If a Java or Python service already owns it, adding
// Auth.js usually means two session systems that must agree — which
// is worse than forwarding one cookie.

// Whatever the design, the rules from the Full-Stack track hold:
//   - httpOnly cookie over a token in localStorage
//   - same-site if at all possible; localhost hides the difference
//   - one shared refresh for concurrent 401s
//   - a complete logout clears the server session AND the caches