for what it's worth i use supabase because it's the fastest way to get from 0-1 for app development. most backend stuff for getting off the ground is not very interesting so getting the graphql api, oauth integration, db migrations, some user authorization story for free is what i'm looking for from supabase.
I’m using Supabase for similar reasons but there’s one specific situation I’m trying to sort out.
Say you have a user “profile” which includes their privileges - like say a column named “privileges” which is some JSON object denoting what they can/can’t do.
Even with RLS, how do you ensure that a user can’t simply make a curl call with their own JWT to elevate their own privileges?
Basically, how to enforce column level security?
The best thing I can think of is to place “privileges” in a child table and only let the service account update that table.
Thanks for sharing. Wasn’t aware of this. Will check it out today.
For now, I figured I’d have an BEFORE UPDATE trigger which compares the md5(NEW.privileges::text) with md5(OLD.privileges::text) and raises an error if they don’t match.
Not sure how to bypass the trigger for service accounts.
You could create a trigger that always keeps the value the same unless user has privileges to change it. Or alternatively the RLS rule could check if the column is being updated and abort the call if it is. I’m using a different table that is read-only to regular users to accomplish this.