https://supabase.com/ logo
Join Discord
Powered by
I suggest adding the ability to query (read-only) ...
# ideas-and-suggestions
m
I suggest adding the ability to query (read-only) the auth.users table directly with a service key. Many production apps need this ability...
Copy code
js
// In my case, I need to add additional users as 'owners' of a record using their email address

// Find user by email
const { data, error } = await supabase
  .from('auth.users') // Not possible now
  .select()
  .eq('email', 'user@gmail.com')

// Then use the user's data for some business logic
Some developers have used workarounds like creating a public.users table which replicates relevant data from the auth.users table using triggers. This feels like a hacky workaround to me... I would much rather avoid this unnecessary redundancy / potential for data inconsistency down the line. (See: https://nikofischer.com/supabase-how-to-query-users-table) Edit: I've copied this feature request to the git repo: https://github.com/supabase/supabase/issues/4715
s
I'm almost certain this is currently possible, you just need to set the correct schema when you are initializing the supabase library.
Also using a secondary table is not a workaround, the rule is that you don't manipulate data in a schema that doesn't belong to you. Querying such a table should only be possible on the server side, there is a lot of sensitive data in that schema/table.
m
Found relevant docs: https://supabase.com/docs/reference/javascript/initializing#api-schemas and settings https://gyazo.com/20a9438849777864580611523b59b42f ... I assume that to do this you would need to add the auth schema to the "Extra search path" setting and then make sure to enable RLS to every table in the auth schema to prevent anon clients from being able to read/mutate freely 🤔 (and then hope that enabling RLS will not interfere with any auth functionality)
Agreed, I only suggest read-only service-key access.
@User > I can see how you view that as a workaround but couldn’t you consider it a benefit to separate the actual db auth and functionality from your app’s permissions? Seems like you could easily get into a risky situation without an intentional abstraction. @User > Using triggers is the best way! Even though it's data duplicated it still is safer as you can use RLS and your not accessing the GoTrue service's data on its own Warming up to it; just seems less convenient from a dev-experience perspective to set this up, but a larger sticking point in my head is the data redundancy / potential for inconsistency. (E.g. user updates their email with 3rd party provider, email updates in auth.users table without updating in the replicated public.users table) Going to assume this problem can also be solved by using triggers though? 
E.g. when auth.users.email changes, replicate to public.users.email
I'm still unclear about how read-only service-key-only access would add significant risk... apparently there is already an undocumented supabase.auth.api.listUsers function (https://github.com/supabase/supabase/issues/4715#issuecomment-1002213887) exposed which means that this data is already available for access with a service key...? I only suggest adding the ability to read the users table more surgically with .match filters, etc. Functionality like this would help avoid the need to learn & set up triggers / produce redundant data / increase surface area of codebase unnecessarily.
h
> exposed which means that this data is already available for access with a service key...? Its a gotrue admin api endpoint > Going to assume this problem can also be solved by using triggers though? Yup triggers solve it
PreviousNext
Powered by