Hacker News Reader

Hacker News

Comment by andymitchell | Hacker News Reader

Parent Full thread

andymitchell

Thanks Paul, Oso looks great.

Re: RLS:

Pros

- The simplicity+security is hard to beat

- Supabase is built around it. I really want the purity of just one platform.

Cons (in order)

- Our enterprise customers need regular oversight of policy + logs for their compliance (and our ongoing relationship). RLS doesn't expose that afaik.

- RLS can't control access to API end points in places like Edge Functions (again, afaik). Same for any 3rd party systems you might have mixed in.

- In my experience, RLS has quite a few foot guns in it as schemas migrate and evolve (security gaps open up, or recursion bites you).

View on HN

> 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...

Replacing Kong with Deno is a great step (and by simplifying the stack, in line with the elegance I love Supabase for).

- My request with Supabase Logs is that they're easy to format in ways auditors expect (i.e. similar to major tools). That would be a headline benefit, because:

[1] As your customer, I have an easier time with SOC2

[2] In turn, I can pitch that to our enterprise customers: "your compliance will be easier, as your policy and log audits with us will match your other vendors"

I'm going to shoot this to your support channel, but a little more tiny feedback:

- There's no local way for a webhook Edge Function to flag "--no-verify-jwt", which means my local test environment can't be consistent with staging.

- I'm having to use Edge Functions for webhooks despite Postgres Functions being more desirable, because either Kong or PostgREST always requires a JWT. I'm guessing the switch to Deno will make this solvable.

Hey Andy,

If you use Supabase CLI to serve functions locally, you can use the `--no-verify-jwt` flag, ie. `supabase functions serve --no-verify-jwt` will skip JWT checks locally.

Is that what you're after? if you have any further issues with serving functions locally, can follow up on the support ticket.

I work on logs at Supabase.

What format(s) would you need?

Also fwiw, if this is self-hosted I'm sure you can export them from BigQuery in an acceptable format.

And if this is Supabase hosted, you can reach out to support and we can do that for you.

Log drains is high on the list for the hosted platform too.

Some additional feedback: In my opinion testing RLS is a problem.

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.)

we have a lot of work to do for migrations and testing, especially RLS.

for this Launch Week we focused on generating policies (more on that in tomorrows launch week). This is hard for a lot of our audience who aren't familiar with SQL.

In the next few months we'll work on simulating a policy - being able to choose a specific user and see what data would be returned for that user.

We also have `supabase test db`, in case you missed it. It wraps pgTAP and pgProve so that you can write database tests.

> recreated without 'WITH (security_invoker)' even though they had security_invoker turned on before

we use migra for diff'ing. Thanks for raising this - we'll file a bug report asap.

Great, thank you for the reply! The simulation a policy sounds exciting. Looking forward to the news.

follow up on the "security invoker" - we've filed a bug report here which you can follow: https://github.com/djrobstep/schemainspect/issues/86

Reply on news.ycombinator.com