-
Notifications
You must be signed in to change notification settings - Fork 396
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should the admin
create user handler of Auth create identities based on the provider under the hood?
#1577
Comments
admin
create user func of Auth create identities based on the provider under the hood?admin
create user handler of Auth create identities based on the provider under the hood?
hi @rexwangcc,
The admin user create endpoint requires either an email or phone number to be passed in - there is an assumption made here that the user created will have either an email / phone identity, depending on which one was provided initially.
Yes, that's fine because when the user signs in with google, there will be a new google identity created and it will be linked to the user since they share the same email.
Currently, it doesn't enforce anything but eventually, the goal is to decouple having unique emails for OAuth identities (see #214). |
closing this issue since it's more of a question |
Thanks for the reply / help! We ended up leaving the "redundant" |
@kangmingtay I think being able to specify provider when using supabase.auth.admin.create_user() would be incredibly helpful. Implementing SSO with invites and running into this. Having to modify identities table under the hood to get the expected behavior... Also can only link OAuth identities, not SSO or email to another one causing a lot of these issues. Happy to discuss further as well but would love to see more attention to these methods |
Bug report
Describe the bug
POST /admin/users
does not really respectprovider
fields when they are notemail
.To Reproduce
Steps to reproduce the behavior, please provide code snippets or a repository:
POST /admin/users
endpoint with any HTTP requests or SDK, such as in Python:the key is to use a provider other than the default
email
.auth.users
, the fieldraw_app_meta_data
looks like:auth.identities
looking like:foo@gmail.com
now, the aforementioned "normalwhich is defo not what we want?
raw_app_meta_data
gets to normal with the right providers in it, except that the default provider now sticks inemail
:while the identities table now have one extra record with
provoder=google
, still, the other one is left untouched (even thelast_sign_in_at
didn't change after a successful email-OTP login)Expected behavior
I would expect the identities table has a row with
provider=google
inserted if thePOST /admin/users
got provider payload that is not a email provider. After some digging, this is not feasible with the current implementation that harding the provider in the transaction:auth/internal/api/admin.go
Lines 361 to 377 in ed2b490
My question now becomes:
email
identity no matter what provider is specified when creating a user via admin endpoints.auth.identities
table, and simply let the user's first login updates the DB?provider=email
record inauth.identities
do at all? I tried deleting it from the underlying DB table and still being able to login with Email OTP.Thank you so much!
The text was updated successfully, but these errors were encountered: