Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RLS on auth.users table for GOTRUE_JWT_ADMIN_ROLES #1841

Open
andrearoscognamiglio opened this issue Nov 15, 2024 · 0 comments
Open

RLS on auth.users table for GOTRUE_JWT_ADMIN_ROLES #1841

andrearoscognamiglio opened this issue Nov 15, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@andrearoscognamiglio
Copy link

andrearoscognamiglio commented Nov 15, 2024

Hi everyone! I'm using a self-hosted version of Supabase on my local machine via Docker. I'm trying to activate RLS on the auth.users table and apply custom policies to allow deletion from auth.users only when the Bearer Token in the request has a specific value in the email claim.

By default, RLS is disabled on the Auth schema, but I enabled it through SQL and also wrote a custom policy. I have a NestJS microservice that needs to allow deletion through a related endpoint, but I’m encountering issues.

If I use a client with the SERVICE_ROLE_KEY, the user is recognized as service_role:

this.supabase = createClient(
  this.SUPABASE_BASE_URL,
  this.SUPABASE_SERVICE_ROLE_KEY
);

In this setup, the service_role has the bypassrls privilege by default, which allows it to delete any user without going through any policies.

On the other hand, when I use the SUPABASE_SERVICE_ANON_KEY, the user recognized is anon, and it lacks access to the auth.users table.

I also tried revoking the bypassrls privilege for the service_role user. Although the console shows success for these commands:

ALTER ROLE service_role WITH NOSUPERUSER;
ALTER ROLE service_role WITH NOBYPASSRLS;

the service_role user still bypasses RLS on the auth.users table.

I changed the GOTRUE_JWT_ADMIN_ROLES variable to set a new role (administrator) as the admin role instead of service_role, but even then, any user token with this role bypasses RLS.

Next, I tried using Axios with a "user-specific JWT" as described here. However, if the Bearer token in the Axios request contains the role specified in GOTRUE_JWT_ADMIN_ROLES, RLS is still bypassed.

this.supabaseAdmin.defaults.headers.common['Authorization'] = authorization; 
this.supabaseAdmin.defaults.headers.common['apikey'] = apikey;        

const response = await this.supabaseAdmin.delete('/' + userId);

Here’s the response in the auth log when using a Bearer token with a role claim different from service_role:

[
  {
    "component": "api",
    "error": "this token needs to have one of the following roles: service_role",
    "level": "info",
    "method": "DELETE",
    "msg": "this token needs to have one of the following roles: service_role",
    "path": "/admin/users/c445c102-d8d1-4b45-be04-70f926287099",
    "referer": "http://localhost:3000",
    "remote_addr": "172.20.0.3",
    "request_id": "04507e6d-f815-4c38-96cb-8137ebc5818f",
    "time": "2024-11-14T20:07:57Z",
    "timestamp": "2024-11-14T20:07:57Z"
  }
]

I’m looking for a way to activate RLS and enforce policies on auth.users. Any help would be greatly appreciated. Thanks in advance!

@andrearoscognamiglio andrearoscognamiglio added the bug Something isn't working label Nov 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant