https://supabase.com/ logo
Powered by
#help
Title
# help
i

ian_

05/14/2022, 3:50 PM
I know there's auth.uid() available in rls policies, but I'm using discord. is there a way to access 
supabase.auth.user().identities[0].identity_data.provider_id
within an RLS policy?
n

Needle

05/14/2022, 3:50 PM
Hello @ian_! This thread has been automatically created from your message in #843999948717555735 a few seconds ago. We have already mentioned the @User so that they can see your message and help you as soon as possible! Want to unsubscribe from this thread? Right-click the thread in Discord (or use the ``...`` menu) and select "Leave Thread" to unsubscribe from future updates. Want to change the title? Use the ``/title`` command! We have solved your problem? Click the button below to archive it.
b

burggraf

05/14/2022, 7:03 PM
This is the function for auth.uid():
Copy code
create or replace function auth.uid() returns uuid as $$
  select nullif(current_setting('request.jwt.claim.sub', true), '')::uuid;
$$ language sql stable;
so you'd have to look to see if provider_id is saved in the jwt (I don't think it is)... If it's not, you'd have to do a lookup on the auth.identities table, which won't scale well, but it's doable.
n

Needle

05/14/2022, 7:03 PM
ian_ (2022-05-14)
i

ian_

05/14/2022, 7:06 PM
thanks! how bad is the scaling issue?
of course it depends on the app, but is doing a lookup each time really bad or fine unless there are hundreds of users (it'll be fine for my mvp i guess?)
b

burggraf

05/14/2022, 7:40 PM
Yes for an mvp it's fine, and fine if it's only used infrequently.
But let's say you put something like this on a table, then select 100 rows from that table. It's gonna run 100 times just for that one select.
That's the scaling problem I'm talking about.
so better to find a more efficient way to do things
g

garyaustin

05/14/2022, 11:05 PM
I think if you put your lookup in a "stable" function like the one above then you will only do one lookup no matter how many rows you search. That assumes you are looking up the provider_id for the user making the call using their auth.uid() so that will never change during the RLS for this operation for each row processed.
Powered by