You create a new user in your Firebase project by calling the createUserWithEmailAndPassword method or by signing in a user for the first time using a federated identity provider, such as Google Sign-In or Facebook Login.
https://firebase.google.com/docs/auth/web/manage-users#create_a_user
This seems handy and meant my "register" or "sign up" function was basically the same as my "login" function.
However from the customer's perspective it's confusing. E.g. if they come to the app and forget they used email/password to sign-up and click "Sign in with Google", click accept in the OAuth popup, then they get logged in to a brand new account they've never used before and of course their previous data/history/purchases are absent.
If a new customer signs in via OAuth, I want to receive the auth/user-not-found error as listed in the API docs here so that I can present the "normal" UX of saying "You don't have an account with those credentials, please sign up first" or similar to apply some friction and help the user to realise they're on the wrong path. i.e. I want sign up to be completely independent from sign in and prevent accidental, spurious accounts being created.
BTW I understand (and have tested) that if a customer subsequently uses a second provider which shares the same email address already registered, then Firebase does some clever stuff to migrate or unify the accounts. But I can't be sure a customer's Google ID would match the email they used with an email/password account creation (e.g. work vs personal or other reasons) so there would still be duplicate/spurious accounts. There's also the "one account per email" option to tweak this)
I actually find it curious that there don't seem to be any discussions about this, as the lack of a "don't auto-register" flag prevents a typical UX supporting a clear difference between "new here? signup" onboarding vs. "got an account? login" for existing customers. So perhaps I'm missing something obvious.
0 comments:
Post a Comment
Thanks