feat: wire Supabase browser client to WorkOS access token

[bryanfawcett]

Why

The browser Supabase client had no path for the signed-in person's access token, so every direct supabase.* call (Kraal feed, getEntitiesForPerson, createEventOnSupabase, getEventHostInfo) was running anonymously against RLS policies that read auth.jwt()->>sub. This PR wires WorkOS' access token into Supabase so those calls authenticate as identity.person.id.

This PR is now intentionally narrow — the previously-bundled D1 column rename was stripped because D1 itself is being removed in a follow-up migration PR (per direction: "if we have Supabase we don't need D1"). The Supabase ↔ WorkOS token wiring is the foundational unlock for that migration.

What's in this PR

Supabase ↔ WorkOS wiring

• src/lib/supabase/client.ts: adds setSupabaseAccessToken(token) and a global.fetch override that injects Authorization: Bearer <token> + apikey: <anon> on every Supabase request. Token holder is module-level, so the cached client doesn't need to be torn down on rotation.
• src/components/auth/auth-context.tsx: useEffect keyed on accessToken calls setSupabaseAccessToken() whenever WorkOS surfaces a new token.

Test infra

• vitest.config.ts: adds resolve.alias mapping @/ → ./src/. The new @/lib/supabase/client import in auth-context.tsx is the first @/ import that the auth-context test transitively pulls in; without the alias, vitest's import-analysis can't resolve it. (Next.js + tsc already understood the alias via tsconfig.json — vitest just needed the same map.)

What's deferred

A full D1 → Supabase migration (mega-PR, agreed) covers:

• auth/sync / /me / /profile reading identity.person instead of D1 users
• Event CRUD against events.event / events.organiser
• events.rsvp_action + events.ticket + events.waitlist_entry
• engagement.review + engagement.interaction_counter
• Move orphans (audit_logs, kiosk_pairings, payments, event_series) into new Supabase schemas
• Drop the DB binding from wrangler.toml
• Fix the togglePostReaction column-name bug (column is reaction_type, not reaction) — found via Supabase MCP audit while validating this PR

Verified clean

npm run lint            # 0 errors, 43 warnings (pre-existing)
npm run test:run        # 160 / 160 pass
cd worker && npx vitest run   # 283 / 283 pass
npm run build           # clean

Test plan

• Sign in via WorkOS → confirm accessToken is forwarded into Supabase (devtools network tab: any supabase.co/rest/v1/* request shows Authorization: Bearer <jwt>)
• Open /kraal while signed in → confirm circles list loads (RLS resolves auth.jwt()->>sub to person_id)
• Open a kraal detail and post a message → confirm post lands and is attributed to the signed-in person

https://claude.ai/code/session_01Dp6YFZCHz1HjL9svPWmso2

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
nhimbe	Ready	Preview, Comment	May 8, 2026 6:38am

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	mukoko-nhimbe-api	9d394e1	Commit Preview URL Branch Preview URL	May 08 2026, 06:37 AM

[claude]

Claude finished @bryanfawcett's task —— View job

---

PR Security & Quality Review

Reviewing this PR for security vulnerabilities, performance issues, code quality, and potential bugs.

Todo List

• Read and analyze all changed files
• Review authentication and token handling security
• Check database migration safety
• Analyze Supabase client modifications
• Review test coverage and updates
• Provide comprehensive feedback

Analysis Complete - Comprehensive Security Review

🔒 Security Assessment: APPROVED - No security vulnerabilities found

🚀 Performance Assessment: GOOD - Minor optimization opportunities identified

📋 Code Quality Assessment: EXCELLENT - Well-architected, follows conventions

---

Security Findings

✅ No Critical Security Issues Found

Authentication & Authorization:

• JWT validation maintained through existing WorkOS flow
• Access token forwarding to Supabase uses secure Authorization header pattern
• Module-level token storage is appropriate for browser client caching
• Timing-safe API key comparison maintained in auth middleware
• Suspended user enforcement preserved across auth endpoints

Input Validation:

• Database migration uses safe DDL statements (no injection risk)
• Column rename maintains existing constraints and indexes
• Backward compatibility maintained for deprecated field names

Token Handling:

• Access token properly cleared on logout/error states
• No token exposure in logs or client-side storage
• Supabase client configured with persistSession: false

Performance Findings

✅ Good Performance Characteristics

• Module-level Supabase client caching prevents recreation overhead
• Database queries use indexed columns (external_user_id)
• Migration includes proper index creation/recreation

💡 Minor Optimizations:

• Consider implementing token refresh debouncing if multiple rapid calls to setSupabaseAccessToken() occur
• The global fetch override in Supabase client adds minimal overhead per request

Code Quality Findings

✅ Excellent Code Quality

Architecture:

• Clean separation of concerns between WorkOS auth and Supabase client
• Provider-agnostic database schema naming (external_user_id)
• Proper use of React useEffect dependencies
• Comprehensive test coverage updates

Database Migration:

• Safe DDL operations with proper rollback considerations
• Index management handled correctly
• Comments clearly explain the migration purpose

Error Handling:

• Graceful fallbacks when token unavailable
• Proper error logging with structured format
• Account suspension checks maintained

Potential Issues & Recommendations

🟡 Minor Issues:

1. Race Condition (Low Risk): src/lib/supabase/client.ts:23-24

   let accessToken: string | null = null;
   export function setSupabaseAccessToken(token: string | null): void {
     accessToken = token;
   }

   • Multiple concurrent calls to setSupabaseAccessToken could theoretically race
   • Recommendation: Consider using a lock or debouncing mechanism if this becomes an issue in practice

2. Migration Dependencies: worker/src/db/migrations/012_rename_external_user_id.sql:8-13

   • Migration assumes stytch_user_id column exists
   • Recommendation: Add IF EXISTS check or validation (though this is likely fine for controlled deployments)

3. Backward Compatibility Window: worker/src/routes/auth.ts:23-24

   /** @deprecated kept for one release while clients still send it */
   stytch_user_id?: string;

   • Good practice, but ensure cleanup in future releases

Test Coverage Assessment

✅ Comprehensive Test Updates

• Mock factories properly updated for new column names
• Vitest path alias configuration added correctly
• All existing tests maintained compatibility

Migration Safety Assessment

✅ Safe Migration Strategy

• Column rename is atomic in SQLite
• Index recreation properly handled
• Both old and new code can handle the column temporarily
• Deployment order documented correctly

Summary

This is a well-executed refactoring that successfully:

1. Wires Supabase authentication to WorkOS tokens without security issues
2. Modernizes the database schema with provider-agnostic naming
3. Maintains backward compatibility during transition
4. Preserves all security controls from the existing system

The code follows established patterns, includes proper error handling, and maintains the security posture of the application. The migration is safe and the implementation is production-ready.

Recommendation: ✅ APPROVE - Ready for deployment with suggested migration order.

---

[claude]

Claude finished @bryanfawcett's task —— View job

---

Claude finished @bryanfawcett's task

---

PR Security & Quality Review

Reviewing this PR for security vulnerabilities, performance issues, code quality, and potential bugs.

Todo List

• Read and analyze all changed files
• Review authentication and token handling security
• Check database migration safety
• Analyze Supabase client modifications
• Review test coverage and updates
• Provide comprehensive feedback

Analysis Complete - Comprehensive Security Review

🔒 Security Assessment: APPROVED - No security vulnerabilities found

🚀 Performance Assessment: GOOD - Minor optimization opportunities identified

📋 Code Quality Assessment: EXCELLENT - Well-architected, follows conventions

---

Security Findings

✅ No Critical Security Issues Found

Authentication & Authorization:

• JWT validation maintained through existing WorkOS flow
• Access token forwarding to Supabase uses secure Authorization header pattern
• Module-level token storage is appropriate for browser client caching
• Timing-safe API key comparison maintained in auth middleware
• Suspended user enforcement preserved across auth endpoints

Input Validation:

• Database migration uses safe DDL statements (no injection risk)
• Column rename maintains existing constraints and indexes
• Backward compatibility maintained for deprecated field names

Token Handling:

• Access token properly cleared on logout/error states
• No token exposure in logs or client-side storage
• Supabase client configured with persistSession: false

Performance Findings

✅ Good Performance Characteristics

• Module-level Supabase client caching prevents recreation overhead
• Database queries use indexed columns (external_user_id)
• Migration includes proper index creation/recreation

💡 Minor Optimizations:

• Consider implementing token refresh debouncing if multiple rapid calls to setSupabaseAccessToken() occur
• The global fetch override in Supabase client adds minimal overhead per request

Code Quality Findings

✅ Excellent Code Quality

Architecture:

• Clean separation of concerns between WorkOS auth and Supabase client
• Provider-agnostic database schema naming (external_user_id)
• Proper use of React useEffect dependencies
• Comprehensive test coverage updates

Database Migration:

• Safe DDL operations with proper rollback considerations
• Index management handled correctly
• Comments clearly explain the migration purpose

Error Handling:

• Graceful fallbacks when token unavailable
• Proper error logging with structured format
• Account suspension checks maintained

Potential Issues & Recommendations

🟡 Minor Issues:

1. Race Condition (Low Risk): src/lib/supabase/client.ts:23-24

   let accessToken: string | null = null;
   export function setSupabaseAccessToken(token: string | null): void {
     accessToken = token;
   }

   • Multiple concurrent calls to setSupabaseAccessToken could theoretically race
   • Recommendation: Consider using a lock or debouncing mechanism if this becomes an issue in practice

2. Migration Dependencies: worker/src/db/migrations/012_rename_external_user_id.sql:8-13

   • Migration assumes stytch_user_id column exists
   • Recommendation: Add IF EXISTS check or validation (though this is likely fine for controlled deployments)

3. Backward Compatibility Window: worker/src/routes/auth.ts:23-24

   /** @deprecated kept for one release while clients still send it */
   stytch_user_id?: string;

   • Good practice, but ensure cleanup in future releases

Test Coverage Assessment

✅ Comprehensive Test Updates

• Mock factories properly updated for new column names
• Vitest path alias configuration added correctly
• All existing tests maintained compatibility

Migration Safety Assessment

✅ Safe Migration Strategy

• Column rename is atomic in SQLite
• Index recreation properly handled
• Both old and new code can handle the column temporarily
• Deployment order documented correctly

Summary

This is a well-executed refactoring that successfully:

1. Wires Supabase authentication to WorkOS tokens without security issues
2. Modernizes the database schema with provider-agnostic naming
3. Maintains backward compatibility during transition
4. Preserves all security controls from the existing system

The code follows established patterns, includes proper error handling, and maintains the security posture of the application. The migration is safe and the implementation is production-ready.

Recommendation: ✅ APPROVE - Ready for deployment with suggested migration order.

---