https://supabase.com/ logo
Join Discord
Powered by
I'm new to supabase so this might be something rea...
# javascript
p
I'm new to supabase so this might be something really basic, but I've spent a bunch of time and can't figure it out. I've setup email/password login. On signUp, I setup a sync so that a row is created in the "profiles" table. After creation of the user, I am trying to update the profiles table with the additional info data 'username' and 'fullName'. But I can't seem to update the table
s
This won't work this way as the user has just signed up and the supabase client doesn't have the access_token to know who is making the request to the 
profiles
table which I assume you have row level security (RLS) turned on on.
p
any recommendations?
s

https://www.youtube.com/watch?v=0N6M5BBe9AE▾

Use a Postgres trigger instead, the video above is really good explaining how this works.
p
use it how?
s
Please watch the video I linked above
p
as I stated in my original question "I setup a sync so that a row is created in the "profiles" table". Meaning, I have already setup a trigger that creates a row in my profiles table that is unique to the user. I can't create that profile with username and fullName since this doesn't exist in the auth.users table. So I am then trying to write to the profiles table and its not working
s
You will need to add those as additional data to the 
signUp
function and pull them out through the trigger, so you will need to recreate your trigger function.
You can have a look at my code in this project to see how to retrieve the additional data inside of your trigger function https://github.com/silentworks/waiting-list/blob/main/migrations/00001-handle_new_profile_function.cjs#L7
You can see my 
signUp
function here which has the additional data https://github.com/silentworks/waiting-list/blob/main/src/lib/data/queries/users/auth.js#L20-L29
p
thanks! Got it working
I wasn't aware of the second parameter you can pass signUp
Copy code
const { error } = await supabase.auth.signUp(
                    { email: formData.email, password: formData.password },
                    {
                        data: {
                            full_name: formData.fullName,
                            username: formData.username
                        }
                    }
                )
and this as my trigger
Copy code
create or replace function public.handle_new_user() 
returns trigger as $$
begin
  insert into public.profiles (id, email, username, full_name)
  values (new.id, new.email, new.raw_user_meta_data->>'username', new.raw_user_meta_data->>'full_name');
  return new;
end;
$$ language plpgsql security definer;

create trigger on_auth_user_created
  after insert on auth.users
  for each row execute procedure public.handle_new_user();
c
I have I think related questions: 1. This will update profiles before the email is verified, right? Is that ok? 2. Is there a standard/common way to avoid that in case you don't like the behaviour? It seems like the data -> trigger -> table would still be required, but perhaps a separate table (is it possible to id by the verification token rather than the user? Is this meaningful?) And then a second trigger to move to profiles when email is verified (i.e. the verification token is used)?
s
1. Yes this is correct, no verification would have happened at this point. 2. Your other option is to provide the user with the username form after they have verified and signed in.
c
I see (without adding triggers or additional information) that the data object is stored in the session localstorage object under current_session.user.user_metadata. Is there an event triggered by verification that I could use to draw this information into the profiles or user tables? Or is it better to just trigger with the 
after insert on auth.users
? Is the verification also part of auth.users? (i.e., can I run 
after update on auth.users when new.role = "authenticated"
or similar? Related, is there a page describing the schema for the built-in tables?
s
You could indeed setup a trigger to run after an 
update
instead of 
insert
and check if the verified filed has changed, but this feels like a lot of work with not much value. Because if you set the username before the user is verified it isn't really causing any issues there. You can view the schema from the table viewer inside the dashboard by selecting the auth schema or by using a SQL desktop client like TablePlus or Beekeeper Studio.
c
Ah, I didn't find a page, but I do see I can run selects against auth.{users,identities,...} and read them in a postgres tool.
Ok - thanks!
@User I see the schema dropdown in the dashboard now, thanks for pointing that out. Missed it before.
s
No problem, its easy to miss.
PreviousNext
Powered by