Threads
Loading user profile...
IshwaryaSuresh proposes three improvements to the policy editor in Supabase Studio: aligning role defaults with documentation, including 'to' clauses in policy templates, and addressing grant issues in the editor. Cenk KURTOĞLU supports these suggestions, highlighting their potential to prevent common security issues and offering to contribute to the implementation.
IshwaryaSuresh proposes moving the RLS verification feature into the policy editor to improve usability. The current setup requires users to remember to visit a separate verification tool, which can lead to unnoticed strict policies. A prototype is provided to demonstrate the proposed changes, including intent-first authoring and a live result panel. Cenk KURTOĞLU supports the idea, highlighting current issues with the policy editor and suggesting additional features for better policy validation.
Since this is paused pending a direction call, I spent some time on where I'd take it and built it out: **https://ishwaryasuresh.github.io/deny-by-default/** Short version: I think the tester was the right capability in the wrong place. A separate verification surface is one you have to remember to visit, and the moment you most need it is the moment you don't know you need it, because a too-strict policy looks exactly like no data. Moving the same capability *inside* the policy editor, so that seeing the result is on the default path to saving, gets the value without asking anyone to change a habit. The prototype on that page runs a real RLS interpreter over sample data (grants → role → permissive `OR` → restrictive `AND`), so you can drive it rather than take my word for it. Worth trying: set the caller to a logged-out visitor and note that it distinguishes *"no policy reached you"* from *"a policy reached you and matched nothing"*. Those are opposite bugs that look identical in production, and they're the largest pattern in the 438 discussions I coded (34.2%). On the two pieces of feedback already in this thread: - @MoAfshar's ask for UPDATE testing looks solvable with impersonation inside a transaction that rolls back. The real exception is tables whose triggers make external calls, and those are detectable ahead of time, so the honest move is to disable the write preview on those specific tables rather than withhold write testing everywhere. - Worth noting for scoping: per the docs, writes already fail *loudly*. A missing grant and a `with check` violation both raise `42501`. Only a `using` filter is silent. So a write tester is arguably less urgent than a read one, which is the opposite of where I started. Longer write-up and the coded research are in [a Feature Requests thread](https://github.com/orgs/supabase/discussions/49608) so it's somewhere upvotable rather than buried in a comment.