Because I'm a dummy, can someone tell me what nuan...
# off-topic
d
Because I'm a dummy, can someone tell me what nuances there are when using RPC regarding RLS?
g
Normal (security invoker) Postgres functions will use RLS policies as the user making the call. So with rpc the role/jwt of the user making the call to the API. If you declare the function as security definer (privileges of creator of function) then it will normally bypass all RLS on tables and you need to enforce security in the function itself.
d
Ah that makes a lot of sense. So by default it's the invoker of the rpc. And is that the opposite of views? Where the default for views is creator?
g
Not even sure views has an option to "be the user"...
s
For views, you would bake your auth logic into the view itself using something like a
WHERE some_table.user_id = auth.uid()
. You can always add a
OR auth.role() = 'administrator'
check if you want to be able to see all the data from the view when logged in to the dashboard Next version of Postgres (15?) supports view policies but in the mean time, the above seems the only feasible way to do RLS-like functionality on views
d
That makes a lot of sense. Thank you so much