Create a `supabase.auth.admin.getUserByEmail` function

[madebyfabian]

Feature request

Is your feature request related to a problem? Please describe.

On server-side, I want to check whether a user with a certain email exists before doing a signup. Since for safety reasons, signups on client side return fake "success" data, even though the user already signed up with this email. (https://github.com/supabase/auth/issues/1517)

Describe the solution you'd like

I would like to have an additional method to not only list all users and get one by Id, but also get one by email. So there is supabase.auth.admin.getUserById(1) but not getUserByEmail('[email protected]')

Describe alternatives you've considered

• Using listUsers(), pretty inefficient but would do the trick
• Signing up a user on the client

[hf]

Hey yes this is a good suggestion. Though, we would probably use something like listIdentitiesForEmailAddress since email addresses do not always uniquely identify users.

[ghost]

Hey, I am a new comer here, can I pick up this task?

[J0]

Hey @toff26,

Sorry for the delayed reply - do feel free to take a stab at it and let us know if there are any queries. You'll need to update both supabase/gotrue-js and supabase/supabase-js

Thanks!

[mahendraHegde]

@J0 @hf i don't see an open PR shall i pick this up? I see we need to add

• GET /admin/users/{email} endpoint in this repo
• modify supabase/gotrue-js to use the same
• modify supabase/supabase-js to use the updated method from gotrue-je let me know if anything else i need to keep in mind or i'm on the right path

[MarcusTXK]

hi @JKFSOM, thanks for taking the time to contribute but i don't think we'll be adding this endpoint in - the GET /admin/users endpoint actually allows you to filter for a user's email address already:

for example:

curl -X GET "http://localhost:9999/admin/users?filter=<user_email_address>" -H "Authorization: Bearer ADMIN_JWT"

Originally posted by @kangmingtay in https://github.com/supabase/gotrue/issues/1330#issuecomment-1848007008

Leaving this remark here for easier reference, as this issue has already resolved.

[Ganthology]

Hey @J0 @hf I created a PR to resolve this issue.

The PR adds a getUserByEmail function using the same endpoint mentioned here.

Please let me know if I'm missing anything in the PR, thanks!

[J0]

@Ganthology Thanks for the PR! We'll take a look shortly.

[J0]

Has anyone run the command recently / was anyone able to get it to work?

I think it might have worked at time of writing but has since changed. How was the PR testeed?

async function getUserByEmail(auth) {
    const { data, error } = await auth.admin.getUserByEmail({
      email:'<email>'
    })
  console.log(data)
  console.log(error)
}

but didn't manage to go through. I then tried the curl command:

 curl -X GET 'http://localhost:9999/admin/users?filter=<email>' \
-H "Authorization: Bearer <service token>"

and wasn't able to get a response.

Tried

curl -X GET 'http://localhost:9999/admin/users?page=1&per_page=5' \
-H "Authorization: Bearer <token>"

and was able to find the user though

At first glance it looks like we currently we default the page params to a default value so not sure this branch will be reached

Let me know if anyone has gotten the client lib bindings to work though

[Ganthology]

Hey @J0, I tested this by running the auth service locally.

1. Creating a user through http://localhost:9999/admin/users
2. Then calling http://localhost:9999/admin/users?filter=<URL-encoded-email>
3. I tested with http://localhost:9999/admin/users?page=1&per_page=5&filter=<URL-encoded-email> is able to work as well

I rebuild the latest main branch, and tested locally (docker), was able to get results (status 200)

[J0]

Thanks for the quick turnaround, let me check again and get back

[J0]

Curl command works thank you! I was looking at the wrong query my bad.

For the auth-js bindings it generally seems great. Needed to change some parts of the response destructuring. Will take this to the team during our meeting in the next few hours and get back to everyone on next steps for this PR

[J0]

Hey as an update,

We're going to close the PR in favour of a method like listIdentitiesForEmailAddress as emails do not uniquely identify users (e.g. a given email can be SSO linked and also non-sso linked).

We'll revisit at a later that as the team is currently occupied with a few other tasks