Purpose
Every time a piece of code bypasses normal RLS / Auth rules, it must be recorded here with a rationale. If a bypass is not listed here, it is unintentional and must be removed.
See §3.4 of 2026-04-27-architecture-refactor-master-guide for the policy.
Active Bypasses
| Location | What is bypassed | Justification | Date added |
|---|---|---|---|
All Edge Functions — _shared/supabase-client.ts | Uses service_role key, bypasses all RLS | Edge Functions run server-side with no user session; they must read/write rows owned by other users (e.g. award XP to any user, fan-out notifications). Scoped to Supabase Edge Functions only, never exposed to clients. | 2026-04-27 |
web/lib/supabase-admin.ts | Uses service_role key for Next.js API routes | Admin portal API routes need to read/modify any user’s data for moderation and analytics. Route-level auth check (requireAdmin()) gates every API route before the admin client is used. | 2026-04-27 |
Retired Bypasses
None yet.
How to Add an Entry
When you write code that uses service_role, bypasses RLS, or uses a privileged Postgres role:
- Add a row to Active Bypasses above.
- Include: file path, what is bypassed, clear justification, date.
- Commit the log update in the same PR as the bypass.
If the bypass is later removed, move the row to Retired Bypasses with a removal date.