What's happening here is that I have an app where users just can register if they are invited. By existing users, they need to fill out a form with the invited user's data, and e-mail address. Then these data will uploaded to the firebase database, with an unique generated key by .push(). Then an email is sent by the app to the specified email address, with an unique registration URL. It looks like this: ${host}/register/?uid=${keyGeneratedByPush}. When the invited user clicks on the link, the browser will get the uid from the query string, and gets the data with it from the database. If everything goes well, the user clicks on submit and createUserWithEmailAndPassword() gets called. The problem is the next: the auth() will generate an unique id (uid), but I already have an existing user id (generated by push). What I want to make them the same then if an user logs in, I can get the user.uid, and get the data from the database with it. A possible solution can be to get all the users, loop through them, and find the email address get by the user object, but why if we have ids. So how to make the two ids the same?
You could create a custom authentication provider and use the push ID as your UID there.
But I recommend against doing that. I see the registration/invitation token in the invite as a different entity than the UID that you generate. While (depending on your use-case) there may be a 1:1 mapping between them, the values have different meanings. One identifies a specific invitation sent to a potential user, the other identifies a specific user.
I'd keep a list of the (pending) invitation tokens, and the email address they've been sent to. Then when the user clicks the link in the invitation, you can look up if it's the correct email address (if you care about that), and associate the eventual UID with the invitation code (if you care about that).
Related
I have a list of people with all their personal information (name, first name, date of birth, email, etc.). I created an account for each of these people in my database. I'm using Firebase.
Since I already have all my user's info, I don't want them to type it again when signing up to my website.
So I created a system using a custom token for authentication. I send them as a parameter of an URL to every one of my users.
When the user clicks on the link for the first time: he gets redirected to the signup page with all the fields pre-filled (name, date of birth, email, etc) except for the password. He types the password he wants and gets signed up.
When the user clicks on the link every other time: he gets redirected to the login page. A simple email + password interface with the email field already pre-filled. He types his password and gets logged in.
This is working great BUT I'm wondering: is this bad practice to do so?
Is this insecure to let anyone who gets the email create an account in the name of my user? Should I assume that someone, other than my user, may have total access to my user email account? Should I be prepared for this eventuality?
Since I already have all my user's info, I don't want them to type it again when signing up to my website.
If you already have the user's information, and you are allowed to process it, then it's a good practice to not let the user do something that it's already done.
is this bad practice to do so?
Not at all. That seems to me like a practice that is present almost everywhere. If you want to edit the profile data, you always have the existing data already pre-filled. The user has just to verify it or change it if needed.
Is this insecure to let anyone who gets the email create an account in the name of my user?
That sounds not like the best option if someone else can use that URL and create an account on behalf of the user. Most likely you should consider letting the user create the account only if it can validate the data through an SMS, or any other service that is specific to that user in particular.
Should I assume that someone, other than my user, may have total access to my user email account? Should I be prepared for this eventuality?
Yes indeed. You should always prepare for that. Never trust the users. There's not a perfect world out there.
I have to implement firebase email authentication and want to store data with a field of firebaseUser.uid in that. I want to know if there is any case when the user's uid will be changed so that I don't mess up with the user data as I will be referring it based on the user's uid. So if any user signs up using an email id, it's uid should never change unless he logs in again with a different email.
The UID for a user is assigned randomly and never changes within that project.
I want to design my Firebase database such that only registered user i.e - I have some predefined set of users who will be using application and only they will be able to sign-in. But the problem is I will get UID only after user is authenticated using OTP in phone authentication and I want to set UID as unique id for each user, So how will admin create the user without UID. I need UID for further operations.
I have one solutions but not sure if this is good idea.
I will create one collection as Registered Users with the phone no as unique ID. and users data like name, email etc. And then when user sign in using phone no. I'll first check in this collection if there phone no is present or not. If it present then I'll allow him to sign-in else not. And with that I'll create another collection as Users and move all the users data from Registered Users collection to Users collection with the UID as unique ID.
Let me know if this is correct approach or is there any better approach available for this kind of scenario. Thanks.
I've a project in which a user needs to be signed in by using their email and password credentials.The user must submit his unique id(Roll number) along with email and password at the time of his account creation.
While doing the project, I've used firebase-auth on the login page to use firease.auth().onAuthStateChanged() function.But the issue here is anyone can create their accounts by simply running firebase.auth().createUserWithEmailAndPassword() function in the console without submitting unique id(Roll number).
Now how can I restrict the users from such actions and making them to submit their unique IDs for their account creation
You probably do not want users to have to submit their unique ids when creating an account. If you do require this, then you'll need to add a validator that pings a collection with stored IDs to make sure that the unique Id they are submitting is in fact unique.
Instead, let Firebase create a unique ID for the user and allow them to register by email password.
Once a user registers with the firebase.auth().createUserWithEmailAndPassword() method, if successful it returns an object with auth credentials. in that returned object is a user property that includes a uid key:value
Is it safe to share a user's ID that Firebase creates when a new user is created? I'd like to use it as an easy way to find other people on my platform.
I don't see why it should not be safe, so if it is. Please enlighten me :)
I am not too familiar with your system or how Nintendo does this (not really a gamer) but you can build something like this:
You can display the list of users (using uid, displayName and photoURL which can be obtained using the Admin SDK or by a list you maintain in the Firebase Database, Firestore, etc) to an authenticated user.
Let's say that user wants to add a connection or friend, you can get that user's ID token, the friend's uid and then add that user's uid to that authenticated user's pending connection list after you verify their ID token.
On the other end, you want the other user to accept the connection request (assuming this how your people finder feature works in your app). You would show the list of pending requests. When the user accepts the request, they would send their ID token and once that's verified, you can consider the connection completed.
To summarize, you still need an ID token to confirm the user sending the request and the one confirming it. Otherwise, if you just solely rely on uids, any user can get the uid of other users and try to add them to each other's friends list, etc.
Hopefully this points you in the right direction.