Difference between "anon" and "authenticated" role

[phuoccss]

create table private_schema.table_name

grant
    select
on private_schema.table_name to authenticated;

create view  public.view_name as
select * from private_schema.table_name;

alter view public.view_name owner to authenticated;

I would expect that anon role aka non-logged-in users to not be able to select from the public view, since I only grant select permission to authenticated role. However, this is not the case as postgrest still return data when users are not logged in.

So what is the difference between anon and authenticated and under what scenarios does the api client take on each role?

[steve-chavez]

I would expect that anon role aka non-logged-in users to not be able to select from the public view

Can you double check that you're making the request with the anon role?

I can't reproduce your error. Do this:

create schema private;

create table private.entities( id int, name text);

create view  public.entities as
select * from private.entities;

Go to the API docs(api/default/), select the entities table, select Bash, select the anon on the "Key" dropdown. This will give you a curl snippet that makes the call as the anon role.

Then do:

curl 'https://<ref>.supabase.co/rest/v1/entities?select=id' \
-H "apikey: <the_JWT>" \
-H "Authorization: Bearer <the_JWT>"

{"hint":null,"details":null,"code":"42501","message":"permission denied for schema public"}  

Which should be the expected error from anon.

---

Sidenote:

grant
    select
on private_schema.table_name to authenticated;

create view  public.view_name as
select * from private_schema.table_name;

If you create a private schema, authenticated shouldn't have any privilege on the private schema tables. You only need privileges on the views of the public schema.

[steve-chavez]

@easy-street Reproduced ✔️. Many thanks for reporting that, it's a mistake indeed. I've made a PR: #1536

@universse To fix it in your current project, you can do:

alter default privileges in schema public revoke all on tables from anon;
alter default privileges in schema public revoke all on functions from anon;
alter default privileges in schema public revoke all on sequences from anon;

-- the above will only work for future database objects, to revoke current privileges 
revoke select on all tables in schema public from anon;
revoke usage on all sequences in schema public from anon;
revoke execute on all functions in schema public from anon;

[phuoccss]

Thanks so much for the suggestions.

[mtte]

@steve-chavez the changes you suggested and implemented in #1536 have been reverted again. Why is that? Is it still valid to revoke the privileges of the anon user or is there a reason one shouldn't do that?

[ozum]

@steve-chavez why is #1536 reverted?

[steve-chavez]

@mtte It's still valid to revoke anon privileges.

@ozum That was a change for the local(CLI) Supabase version, while the hosted version still used a privileged anon.

I'd also like to have a non-privileged anon by default(this is the PostgreSQL default, and PostgREST recommendation) but nowadays doing this for Supabase would be a big breaking change. Maybe with your custom roles proposal #11745 we can have a way forward that is also backwards compatible.