7 people reported
All time, since May 6.
RLS rejects authenticated requests
“SELECT/UPDATE-style read access and the underlying auth/JWT pipeline all work correctly - only the INSERT WITH CHECK enforcement appears broken.”
Is this your bug? What gets counted gets fixed. Pile on.
Paste this into your agent. It files your report, with your error and version.
I hit this bug: rapsheet.dev/sheets/supabase/issues/8805/file Follow it to file my report. Show me the text before you send.
No install. No account. Public and anonymous. The link asks your agent for one report, nothing else. What it sends
Authenticated requests rejected by RLS despite valid JWT. PostgREST inserts fail with "new row violates row-level security policy" though sb.auth.getUser() succeeds and direct SQL tests pass.
Is this your bug?
File my report- Where
- PostgREST Data API
- Error text
42501: new row violates row-level security policy for table "<table>"- Versions
- 2.97.0
- How bad
- Some reports say it used to work. Some reports say it blocks them completely.
Not quite your bug?
- Storage uploads fail RLS check3 people
- Storage operations fail with 5032 people
- Admin API rejects secret key3 people
Original reports7, newest first
- Authenticated INSERT always rejected by RLS, even with
with check (true)#50483 - Help :( - Every authenticated INSERT into two specific tables is rejected with an RLS violation via the Data API, but the identical operation succeeds in a plain SQL session with the exact same JWT claims#50265
- Storage RLS rejects all uploads — auth.uid() NULL for ES256 JWTs (project rynswrhabeobtyjthpto)#48526
- Authenticated requests rejected by RLS as if unauthenticated — possibly related to recent JWT signing key rotation#47149
- auth.uid() returns NULL in RLS for live PostgREST requests despite a valid JWT (new JWT Signing Keys) — error 42501, reproduces on a fresh project#47078
- RLS blocking authenticated users after JWT key rotation to ECC P-256#45812
- Storage service rejects ES256-signed authenticated JWTs — 403 RLS violation despite valid token + correct policy#45655