vercel
full_name not saved when doing signup with email verification
The signup works fine, and I see the name and the user printed out (I added the log statements). However, the patch request to update the name on the user table returns a 404:
got user {id: "f79d6fce-6a19-4712-a8d5-00a2563eacf8", aud: "authenticated", role: "authenticated", email: "`[email protected]", phone: "", …}app_metadata: {provider: "email"}aud: "authenticated"confirmation_sent_at: "2021-08-19T11:56:42.870927667Z"created_at: "2021-08-19T11:56:42.867851Z"email: "[email protected]" id: "f79d6fce-6a19-4712-a8d5-00a2563eacf8"phone: ""role: "authenticated"updated_at: "2021-08-19T11:56:45.036149Z"user_metadata: null[[Prototype]]: Object
signup.js:32
got name Adrian Krebs
PATCH https://nqltpulqdgngkiwpnjkj.supabase.co/rest/v1/users?id=eq.f79d6fce-6a19-4712-a8d5-00a2563eacf8 404
The user exists, so why is the update failing with a 404?
const handleSignup = async (e) => {
e.preventDefault();
setLoading(true);
setMessage({});
const { error, user } = await signUp({ email, password });
if (error) {
setMessage({ type: 'error', content: error.message });
} else {
if (user) {
console.log('got user', user)
console.log('got name', name)
await updateUserName(user, name);
setUser(user);
} else {
setMessage({
type: 'note',
content: 'Check your email for the confirmation link.'
});
}
}
setLoading(false);
};
When I turn the email verification off in supabase, it works. That is obviously just a workaround and I would love to hear the proper solution.
This has to do something with the row level security. Only signedIn users are able to update themselves. I wonder how we can solve this with email verification turned on.
@AdrianKrebs @ingokpp
I added an API route to my application that uses the admin client to update the full_name field bypassing RLS. Since the update is done server side it protects the service_role_key but I guess it might still be possible for someone to use the API route to maliciously update a different user's full_name.
Thoughts on solving the issue this way? What alternatives did you consider?
@AdrianKrebs @ingokpp
I added an API route to my application that uses the admin client to update the full_name field bypassing RLS. Since the update is done server side it protects the service_role_key but I guess it might still be possible for someone to use the API route to maliciously update a different user's full_name.
Thoughts on solving the issue this way? What alternatives did you consider?
What if we create an admin api route for the signup itself? This should also include the update of the full name. I think this could be a possible solution to prevent the problem because it's not possible to signup the same person multiple times. What do you think of this?
@AdrianKrebs @ingokpp the proper way (respecting RLS) would be to create a later interface using JWT tokens (signUp only includes email and password) and after using the receive token via link "confirm subscription" to call the function for update (using local storage or cookie to save data as full_name in this example), @reesef a smart solution, it's an exception that supabase should improve, I struggled for 2 days to understand and thanks to @zernonia's help managed to explain me and understand the flow, we need to improvements to supabase documentation and examples
