Reputation: 31385
I'm currently developing a starter kit for my Firebase + Firestore + React apps.
I've been stuck trying to figure out the best way to handle multiple sign-in methods for each user.
At first, I was attempting to do so, using Firebase Auth with the "one account per email" restriction activated (that's the default).
But after a LOT of failed attempts to achieve my intended behavior, I've decided to give up and switch my Firebase Auth to "allow multiple accounts per email".
My main goal here is:
If I'm offering my users 3 sign-up-and-in methods (for example: email/password + Google + Facebook), I feel that I should honor those 3 methods regardless the order that they might have been used.
The fact it that with the "one account per email" restriction that is just not possible, because if your user first signs-up with email/password, Firebase will delete his password if he signs-up with Google the next time. And it will do that so silently that your user will never know why his password is not working anymore (at least that's what I understood from my research and a question to Firebase support).
This is for security reasons, since Google Provider has a higher precedence over other providers (basically because the Google email comes back implicitly verified, in this case). I get that, but I just think that it would make a terrible user experience if you delete a user's password without letting him know that it happened.
I have another question that goes deeper into this issue
But with this question here I would like to know the following:
While allowing multiple accounts per user, I'll have to save my users' data on Firestore using their email
as their uniqueID
, because using multiple accounts/sign-in-methods per email, each account will end up having a different uid
generated by the Firebase Auth system, but they all should have access to the same account on my app, hence I'll have to use their email
as the uniqueID
).
Note: From my app's point of view: every account on Firebase Auth using the same email address corresponds to the same user.
For example:
[email protected] signs-up using email-password (send link to verify his email)
Firebase Auth creates one account for [email protected]/email-password. uid = x
[email protected] signs-up using Google Sign In
Firebase auth creates another account for [email protected]/google-sign-in. uid = y
[email protected] signs-up using Facebook Sign In
Firebase auth creates another account for [email protected]/facebook-sign-in. uid = z
Since every account will have a different uid
, I'll let them all have access to the same data on Firestore using their email
as uniqueID
, which will be the same for each account, in this case.
QUESTION
Although that seems to solve my problem, I'm worried about possible complications that might bring in the future. Any one of you, more experienced Firebase developers, might think of a reason why I shouldn't solve the problem using the approach explained above?
Keeping in mind that from my app's point of view: "the user IS the email" and not the account on Firebase Auth. Each user might have 1, 2 or 3 accounts on Firebase Auth.
Do you see potential issues/conflicts with:
Thanks for the help.
Upvotes: 1
Views: 1287
Reputation: 5272
I don't see any issue with the setup you're describing - and besides, since their email is the only piece of shared identity information you have - it's not like you have much choice. As long as you structure everything based around email address... skipping anything related to the firebase-generated UID, then it should be fine.
One warning I'll give you is that you should pay careful attention to stripping out some special characters from email addresses when you write it in the database. These database docs include information regarding inpermissible characters in a Firebase database key:
If you create your own keys, they must be UTF-8 encoded, can be a maximum of 768 bytes, and cannot contain ., $, #, [, ], /, or ASCII control characters 0-31 or 127. You cannot use ASCII control characters in the values themselves, either.
Many of which are valid portions of an email address.
That's the one big cautionary item that I can think of, otherwise you ought to be good-to-go. Disclaimer that I don't have a lot of experience with FCM, so there might be another consideration I havne't noticed, if you're looking to add a mobile client at some point down the road.
Upvotes: 1