Wrong role claim on PostgREST

[andreivreja]

Hi there,

First of all, congrats on the amazing work you guys have done on Supabase, it’s pretty straightforward!

Having an issue with PostgREST auth (managed Supabase), I’m using the default service_role token to insert data (I wanna lock anon to read only), however, somehow it’s being detected as anon.

At least that’s the conclusion I came to after this behavior:

1. Enabling RLS results in permission error with service_role token (which should bypass RLS).
2. Giving access to role anon on the policy makes it so the insert works, which I guess confirms that somehow it’s using (or defaulting?) anon role.

I can confirm that I’m using the correct token. Not using one would result an authorization failure (from the PostgREST docs, it should default to the anon role; unless that’s an exception in production).

Can’t really seem track this issue down on my own.

Note: haven’t tried generating a new JWT with service_role as the role claim, only tried the default one from the dashboard, but since it’s a JWT this shouldn’t be relevant.

[steve-chavez]

Hey @andreivreja,

Can you double check you're using the service_role JWT? You can paste it in jwt.io and see if the role claim has service_role.

Also note that you shouldn't be using service_role for clients.

[andreivreja]

Oh, so I must include the token both as an apikey and as a bearer token for authorization? Didn't even cross my mind until you directed me to the auto generated snippets on the API tab.

[andreivreja]

Okay yeah, everything works as it's supposed to now. I'm not using the supabase-js, had errors saying that I didn't include an apikey after trying with an auth header, so I assumed it's just a different name, turns out I need to use both headers. Is this some inconsistency or it was just more straightforward to have it this way to account for all uses cases?

Either way, thanks for pointing out the API code snippets, would've spent a lot of time to figure this one out otherwise since the docs/repos didn't really mention anything about this case; or maybe I just didn't find the info.

Keep up the amazing work!

[kiwicopple]

Is this some inconsistency or it was just more straightforward to have it this way to account for all uses cases?

Yeah we had to do this because when we first lauched we didnt have Supabase Auth - only an API key for the API gateway. We added GoTrue + RLS (via PostgREST) for Supabase Auth, and so the "anon" JWT also became API key. We will probably remove this at some stage for simplicity, but for now the API key is useful because it prevents the database from getting DOS'd by unauthenticated requests.

Keep up the amazing work!

Thanks for your kind words @andreivreja

[mstade]

Thanks for that explanation @kiwicopple, I've also been wondering why the apikey header exists. Seems to me that at this point though you could just get rid of it and rely only on JWTs, no?

[kiwicopple]

Very soon! We'll phase it out incrementally from our libraries + backend