https://supabase.com/ logo
Powered by
I am trying to do RLS with Prisma. There is a weir...
# help
n
I am trying to do RLS with Prisma. There is a weird behavior I'm seeing with RLS policy with simple SELECT. Using the deprecated 
auth.role() = 'authenticated'
works however, 
TO authenticated
in RLS policy does not work FOR Prisma Client. (Supabase Client works for both) More details in thread
n
Hello @NanoBit! 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.
n
If I run side by side both Prisma and Supabase clients, The supabase client would return output, but Prisma would not if I used “TO”. If I compare auth.role(), both would return outputs. I already applied the troubleshooting script from the docs.
Code:
Copy code
js
const [, results] = await prisma.$transaction([
          setCurrentJWT(req),
          prisma.customer.findMany(),
        ]);

const { data } = await supabaseServerClient({ req, res })
          .from<definitions["customers"]>("customers")
          .select("*");

console.log(results?.[0]);
console.log("supa side");
console.log(data?.[0]); // Single Customer obj
If I used 
TO authenticated
,
Copy code
js
console.log(results?.[0]); // undefined
console.log("supa side");
console.log(data?.[0]); // Single Customer obj
If I used 
auth.role() = 'authenticated'
,
Copy code
js
console.log(results?.[0]); // Single Customer obj same as above
console.log("supa side");
console.log(data?.[0]); // Single Customer obj same as above
I checked that: the prisma code is running in the same user context by setting jwt in 
request.jwt.claims
and outputting it via 
SELECT
I also tested 
auth.role() <> 'authenticated'
, and both logs show 
undefined
meaning that it's this setting that's affecting the result.
g
The auth.role() gets the data from the jwt claims, which evidently Prisma sets ( I don’t use Prisma). The to method is just looking at the database user. PostgREST sets the user to anon or authenticated. I assume Prisma coming in as the postgres user. I’m not sure where to report this, although I did see a discussion in SB GitHub documenting lots of Prisma/SB issues in the past few days. You can continue to use auth.role() or what ever replaces it in the future to read the jwt. It is needed in functions so can’t go away.
n
Thanks @garyaustin for replying! > I assume Prisma coming in as the postgres user. For my case, I created a separate user 
prisma
with permissions on public schema only on all tables. (no bypass RLS). > The auth.role() gets the data from the jwt claims, which evidently Prisma sets yep, this was the initial intention. > You can continue to use auth.role() or what ever replaces it in the future to read the jwt. It is needed in functions so can’t go away. Oh I see! Although it's a little dirty compared to using the 
TO
operator. > PostgREST sets the user to anon or authenticated I was reading about this and that they take the role from the 
jwt.role
which 
auth.role()
does reference. https://postgrest.org/en/latest/auth.html# My hypothesis right now is that, it does set the role properly, but the user does not change to the 
authenticated
role for some reason. It does change to the logged-in user (via jwt), but does not set the status to 
authenticated
. I'll see if 
SET LOCAL ROLE authenticated;
does something
I solved this by making a 
prisma
acc that acts like authenticator class. Will post my solution later on the discussions for others: https://github.com/supabase/supabase/discussions/7659
n
Thread was archived by @NanoBit. Anyone can send a message to unarchive it.
PreviousNext
Powered by