https://supabase.com/ logo
Powered by
I want my user to be able to provide a display nam...
# gotrue
s
I want my user to be able to provide a display name on sign-up. Can I include it in 
options.data
for 
signUp
, but never have it be part of the JWT again? I'll store it in a 
public.profiles
table using a trigger (I am already creating the profile with a trigger), but I want to be able to set the name in a single step. If it is not possible to have a temporary value in 
user_metadata
, is there a way to do this that doesn't use 
user_metadata
?
s
Yes you can do as @garyaustin has suggested. @shinei why would you run the trigger before insert? how will you know which record its associated to?
s
it has to be run before insert because we need to strip the metadata field
it shouldn't get inserted into the 
auth.user
table
rather, it should be parsed and the display name should be saved into the 
profiles
table
s
You can strip the metadata field after, also not sure what's the relevance of stripping that field when its only temporary data
s
is the metadata field not stored in the 
auth.user
table?
how is it temporary?
that's why garyaustin said to use a before trigger instead of after right?
s
Ok temporary is the wrong phrase but you can delete it in an after trigger, I'm still trying to work out whey you need to delete it at all if it's not used anywhere in your app?
g
Ah, I forgot about a possible foreign key. My profile table does not have a FK back to auth.users. I store the uuid in a regular row. I do this so if the user leaves any posts he has made still reference the profile which I change to guest and clear of user info. I assume the uuid is available in the before trigger, but have never looked.
This also mentions at some point user meta data will not be in the jwt on a future major release. https://github.com/supabase/gotrue/pull/251
s
oh that's interesting
where will it be stored instead?
g
It would still be stored in auth.users, just not passed around in the jwt.
s
oh okay
so like if it's updated later I don't need to worry about updating it in both places
it's better knowing that it's only actually stored in one place
the reason I wanna store it in a profiles table is because other users should be able to access the display names of each other
I can't really do that securely in auth.users right?
g
Profiles table is the way to go IMO. You can access auth.users with an rpc call and a security definer function, but if you already have a profiles table just use that. Unless you are worried about the small increase in jwt size for you your extra info, just have it in both places.
s
my concern with having it in both places is keeping the data in sync
any time I update the user's display name in the profile table, I would have to update it in auth.users as well
how about using a before trigger to insert the data into the profiles table and remove it from the data that's written to auth.users, and removing the foreign key relation?
does that seem like a reasonable thing to do
g
I don't like triggering on a table change coming from a trigger on a table and also then modifying the original table which "might" cause an infinite loop if not careful with types of triggers, etc. Also if you are triggering on an update to the profile table from a user API call, you probably won't have privilege to modify the auth.users table. Then you have to use a security definer function to do the actual update.
s
I don't think it will be available on the before trigger as this is before the record has been inserted,
I think you are overthinking this, you are only using the user metadata as a temporary means to transport that data into the 
public.profiles
table, after that you don't need to update any data in the user metadata in the 
auth.users
table. You can even setup a cron to wipe the existing data if you wish or just leave it there because you will be defining which information you display in your app anyway.
You would just ignore the 
auth.users
table, you don't need to update it in both.
s
but then if a user updates their display name, I would technically still be able to manually access the first name they'd specified, right
nono it doesn't modify any table
it just removes the display name field from the data that is about to be written
so it only gets written to the 
profiles
table, and is never written to the 
users
table
it intercepts the write and redirects the data basically
s
As I stated before you are overthinking this, you will only be working with the 
public.profiles
table after you store the information from the 
auth.users.user_metadata
into it, you can completrly ignore the 
auth.users.user_metadata
after that. No need to keep anything in sync because you will be using the display name from the 
public.profiles
table.
I'm doing this in my waiting-list app, the 
fullName
is coming from the 
public.profiles
table https://github.com/silentworks/waiting-list/blob/main/src/routes/manage/_layout.svelte#L9
PreviousNext
Powered by