The reason I ask is - In the documentation I read ...
# off-topic
n
The reason I ask is - In the documentation I read
Copy code
The auth.users table has a JSONB column called raw_user_meta_data
however this is problematic because if a new signUp is called on an email address that already exists it will overwrite the metadata
s
This shouldn't be the case, because if the email already exists then the account wouldn't be created again
If this is happening then its definitely a bug and should be reported
n
ya its def happening I just tested it for a good 10 times. It happens on email validated accounts too
Copy code
const { user, session, error } = await supabase.auth.signUp({
        email: email,
        password: password,
    },{
        data:{
            phone: phone,
            name: name,
            company: company
        }
    })
the password luckily is not overwritten 🙃
s
oooof ok that's a bug
n
where should I report
s
Although its a bug, do remember to not store data inside the
metadata
object, but rather use it as a transport object, it's best to write that data to a table as soon as possible
n
Unfortunately I can't even prevent it because there is no API to check if a user exists 😕
s
Funny you mention this, this is something I'm working on now for a project I'm working on
n
ya there's only a work-around of using a profiles table which is not ideal and immediately takes away from the 'easy auth solution' pitch
s
The profiles table is a part of the easy auth solution pitch
n
lol
s
haha now you know
n
is there a way to know if a user has validated their email
s
You can check the email_confirmed_at field inside the auth.users table, but you can't do this directly inside of the supabase-js library
It would be best to create a view with the
id, email, email_confirmed_at
and then query against that
Copy code
sql
CREATE VIEW public.list_users AS
SELECT id, email, email_confirmed_at
FROM auth.users
Now with the supabase-js library you can do
Copy code
js
const {data, error} = await supabase.from('list_users').select('*').eq('email', 'email_you_wish_to_check_here');

// now you can check email_confirmed_at inside of data
console.log({ data });
Do note though that this table is not protected by RLS, so it shouldn't contain sensitive data or data you don't want anyone who is not logged in to access
The other option is to create a Postgres function to do this and get the value back from that
n
ya I will just build a server-side api that uses the service account to talk to the auth.users table
s
yep that's probably the best option