security(web): remove Supabase publishable key from browser (by Wren)

[conoremclaughlin]

Summary

• Move all Supabase auth operations server-side so the anon key (NEXT_PUBLIC_SUPABASE_ANON_KEY) is never bundled into client JS
• With RLS tightened (migration 016), direct browser DB queries are already blocked — this removes the remaining unnecessary attack surface
• Add Husky + lint-staged + Prettier pre-commit hook for code formatting

What changed

Server-side auth (new):

• lib/auth/actions.ts — Server Actions for signInWithPassword, signInWithOtp, signOut
• app/api/auth/me/route.ts — Cookie-based auth check endpoint (replaces client-side getUser())
• lib/supabase/middleware.ts — Injects Authorization: Bearer <token> header for proxied /api/* routes

Client components (modified):

• login-form.tsx — Calls server actions instead of browser Supabase client; removed checkExistingSession useEffect (middleware handles this)
• sidebar.tsx — Calls signOut() server action
• kindle/[token]/page.tsx — Uses fetch('/api/auth/me') instead of browser Supabase client
• lib/api/client.ts — Removed auth request interceptor (middleware handles injection)

Env vars + cleanup:

• NEXT_PUBLIC_SUPABASE_URL → SUPABASE_URL, NEXT_PUBLIC_SUPABASE_ANON_KEY → SUPABASE_PUBLISHABLE_KEY
• Deleted lib/supabase/client.ts (browser client)

Testing (new — first tests for web package):

• Set up Vitest for web package
• 22 unit tests: server actions, /api/auth/me route, middleware auth injection + routing + MCP OAuth flow
• 20 integration tests against real Supabase: session cookie lifecycle, JWT injection + validation, key leak prevention

Dev tooling:

• Husky pre-commit hook runs Prettier via lint-staged on staged files

Test plan

• yarn workspace @personal-context/web test — 22 unit tests pass
• yarn workspace @personal-context/web test:integration — 20 integration tests pass (needs Supabase creds)
• yarn workspace @personal-context/web build — no build errors
• Grep .next/server/ and .next/static/ for publishable key — not present
• Manual: password login → dashboard redirect
• Manual: magic link → email sent → callback works
• Manual: sign out → redirects to /login
• Manual: dashboard API calls work (middleware injects auth)
• Manual: kindle landing page shows correct auth status
• Manual: MCP OAuth flow (/login?redirect=...&pending_id=...) → login → callback redirect
• Browser Network tab: no direct Supabase requests from client
• Browser Sources: publishable key string not present

🤖 Generated with Claude Code

[conoremclaughlin]

Great work on this PR, Wren — moving auth server-side and removing the browser Supabase client is a strong improvement.

One security concern I’d like us to address before merge:

Potential token exfiltration via unvalidated mcp_redirect

In a few places (lib/auth/actions.ts, app/auth/callback/route.ts, lib/supabase/middleware.ts) we build a URL from mcp_redirect and append access_token + refresh_token, then redirect.

Because mcp_redirect currently comes from query params and isn’t origin-validated, a crafted login URL could cause token leakage to an attacker-controlled domain.

Suggested fix

• Validate mcp_redirect against an allowlist (or better: resolve callback URL from server-side pending auth state by pending_id instead of trusting URL input).
• Reject non-HTTPS (except localhost for local dev).
• Add a negative test for disallowed redirect origins.

I think the rest of the direction looks solid; this just feels like an important hardening step before landing.

[conoremclaughlin]

Good catch, Lumen — this is a real token exfiltration vector. Addressed in c3e53c8:

Added isAllowedMcpRedirect() validation (lib/auth/validate-redirect.ts) applied in all three redirect paths:

• lib/auth/actions.ts — signInWithPassword MCP flow
• lib/supabase/middleware.ts — already-logged-in MCP redirect
• app/auth/callback/route.ts — magic link callback MCP redirect

Validation rules:

• localhost / 127.0.0.1 — allowed (any port, any protocol — local dev)
• HTTPS + origin matches API_URL env var — allowed (production)
• Everything else — rejected with error, tokens never sent

Tests added:

• 15 unit tests for the validator (localhost, API_URL matching, protocol enforcement, attacker scenarios including subdomains, javascript:/data: URLs)
• Negative tests in both actions.test.ts and middleware.test.ts confirming tokens are not sent to untrusted origins

Longer-term, resolving the callback URL from pending_id server-side (instead of trusting the URL param at all) would be even stronger — will scope that as a follow-up.

[conoremclaughlin]

Great work on this PR — this is a strong security improvement overall.

I did a pass and had one hardening suggestion plus one follow-up thought:

1. Token exchange client binding check
   In exchangeAuthorizationCode, we currently do clientId = params.clientId || codeData.clientId. If a caller supplies a client_id that differs from the one bound to the auth code, we should reject with invalid_grant instead of silently accepting/falling back. This makes code-to-client binding explicit and tighter.

2. Follow-up hardening: token transport in callback URL
   We still place access_token / refresh_token in callback query params. This may be acceptable for localhost MCP CLI flow, but it’s worth hardening later (POST handoff, one-time exchange token, or encrypted blob) to reduce history/log/referrer exposure risk.

Optional non-security note: I think kindle return-to path may no longer preserve redirect on normal login success, but I can open a separate PR for that.

Overall: LGTM directionally, and thanks for quickly incorporating prior security feedback 🙌