| > logs for their compliance Supabase Logs will be fully-integrated with the rest of the supabase stack. Since the Auth JWT flows through the HTTP Authorization header, into PostgREST, then into Postgres, we can pluck the Supabase User ID out of the JWT and store it alongside every log entry. You will be able to reference/join every authorized action in your database to an authenticated user. > RLS can't control access to API end points in places like Edge Functions (again, afaik). also correct, for now. We released the Edge Runtime[0] this week, and plan to use it as a scriptable Proxy. > In my experience, RLS has quite a few foot guns in it as schemas migrate A very fair point. We hope that we'll be able to provide some tooling here. Thanks for all of this feedback - it's incredibly useful. Our team read the HN comments thoroughly and it shapes our ideas for the product going forward. We have some gaps to fill for your requirements, but we'll get there. [0] Deno Edge Runtime: https://supabase.com/blog/edge-runtime-self-hosted-deno-func... |
Additionally, I find it hard to keep a good overview over the rules. E.g., in a multi-tenant application one needs to secure every table with a restrictive rule, and it's easy to make a rule permissive, since that is the default & it's not indicated in the Studio UI.
When generating migrations with 'supabase db diff' views are being recreated without 'WITH (security_invoker)' even though they had security_invoker turned on before, leaving your database exposed. Easy to miss, even when you're aware of that.
RLS is just so full of footguns that I find it hard to justify using it in a production system.
(But otherwise I love Supabase! Great job.)