Skip to content
This repository has been archived by the owner on Apr 16, 2022. It is now read-only.

GRANT api TO anonymous, webuser? #61

Open
ggregoire opened this issue Sep 29, 2021 · 2 comments
Open

GRANT api TO anonymous, webuser? #61

ggregoire opened this issue Sep 29, 2021 · 2 comments

Comments

@ggregoire
Copy link

ggregoire commented Sep 29, 2021

Hi!

Sorry to bother with the following questions, it's probably a misunderstanding on my side.

I created a role api as you did:

-- this role will be used as the owner of the views in the api schema
-- it is needed for the definition of the RLS policies
drop role if exists api;
create role api;
grant api to current_user; -- this is a workaround for RDS where the master user does not have SUPERUSER priviliges 

Then created a policy assigned to api as you did:

-- define the who can access todo model data
-- enable RLS on the table holding the data
alter table my_table enable row level security;
-- define the RLS policy controlling what rows are visible to a particular application user
create policy my_table_access_policy on my_table to api ...

api is the owner of the corresponding view and has access to the table as you did:

alter view my_table_view owner to api;
grant select, insert, update, delete on my_table to api;

However the endpoint my_table_view returns 0 rows to webuser, although the policy allows him to see some rows. Then once I executed:

grant api to anonymous, webuser;

the endpoint and the policy worked as expected.

So my question:

You never do grant api to anonymous, webuser in this project. Is it actually needed or did I miss something?

(And I'm wondering, what's the purpose of grant api to current_user;? I saw the comment but why does master need SUPERUSER privileges to run PostgREST? And how giving api to master solves the issue since api is created without SUPERUSER privileges? I'm on RDS and I tried with both grant api to current_user; and revoke api from current_user; and I don't see a difference, but I might be missing something again)

@ruslantalpa
Copy link
Member

can you post the policy body and the sample curl request (the parameters), without that i am not sure what is wrong, everything seems right (except that last grant, that is wrong).

grant api to current_user; is needed because otherwise alter view my_table_view owner to api; fails since master does not have SUPERUSER privileges to change the view owner. This grand does not relate to the flow of requests coming through postgrest, it's strictly so that alter statement succeeds;

@ruslantalpa
Copy link
Member

for the full picture please also include the grants to my_table_view for anonymous and webuser

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants