I am making a website with login and registration facility using firebase. I have used firebase "Authentication" database to store the registered users.However, "Authentication" database doesnt store anything other then emailid, password and an auto generated UUID.
I need to store more data like username, profile pic etc for a user. I would be using firebase's "real time" database for the same.
My question is what is the best practise to do the same. Should I use the UID as primary key from "authentication" database and keep it as foreign key in my real time database like below:
Authentication db:
Record 1 - Email:abc#test.com; password:somepassword; UID:UID1
Record 2 - Email:abcd#test.com; password:somepassword; UID:UID2
RealTime db structure:
users
|
|--UID1
|
|---Name:Amanda
|---Surname:Waller
|---age:30
|--UID2
|
|---Name:MyName
|---Surname:Mysurname
|---age:39
Or is it better to use email id as primary key instead of using firebase's auto-generated UID. Because in sql we do not generally use the autogenerated ids as primary keys.
It’s better to use the UID. For one thing, you can’t have periods in keys, so if you use email as a key you’ll have to handle that by replacing them with some other character. Also, some forms of authentication don’t require email, like Twitter. Since you can get the UID easily once the user is authenticated, that’s what I’d recommend.
Related
I am trying to make a db model on fire base but I didn't understand the user authentication quite yet in mongo db you can make a document that has all the user data like email for example and passwords in addition to that user data, but in firebase the user authentication is a separate data base , can i make users document that include users data and authentication with in the fire cloud db ? or at least can I connect AUTH and db together ?
Firebase Authentication handles everything from hashing passwords to storing credentials and you don't have to store anything in a database. It also generates a unique UID for each user that can be used to identify user specific data in a database.
For example, if you have a collection "posts" then you can store the author's UID along with post data.
Also check: Firestore data modeling with more than one collection for each user
I'm quite new to firebase and I am looking for best practices using it, maybe I will be able to get some advices here.
What I want to do:
User login using firebase.
Problem:
I save user info in firebase but use SQL server as database where I need that user information as userId
Question: How should I approach that?
Register user on firebase and when I get response with userId and token, save it to my sql database too?
what's my current approach:
At this stage we're thinking of creating new users via admin panel (and then these users can sign in)
Would it be good approach to add user to sql database, send email to finish registration (create pasword) and then add this user to firebase, and with response send request to my backend where I update user that he's verified, add userId and token?
It's very common to store additional information about Firebase Authentication users in your own database. Whether it's good in your use-case is subjective, but it's definitely common.
Assuming that you have a server interacting with SQL server on the user's behalf, be sure to pass the ID token from the client to the server, decode it there, and then use the UID (and other claims) from that token in your database interactions. Don't allow the user to just pass their UID, as that'd be a security risk.
For more on this scenario, see the Firebase documentation on verifying a user through their ID token.
Your approach with an admin panel is a common first approach, but not something I'd recommend. Since you'll need to allow the user's to sign in with email/password, there is nothing keeping them from calling the createUserWithEmailAndPassword API themselves on your project. So I'd recommend leaving the creation completely to the clients, and save yourself from having to consider that an abuse scenario.
If you want to control what users an access the data, store a list of email addresses (since you seem to associate that with uniquely identifying a user already) in the database, and check the email address in the ID token is in the list (and is marked as verified in the token).
Is it possible to change those random UIDs strings in firebase to an integer?
I am using firebase tokens to authenticate on my back-end. In my back-end I also have a table which stores additional user data required for my application. This table has a user id column which is an integer primary key and also an additional firebase_id field to know which firebase uid corresponds to this user. Each time there is an authenticated request on my backend, the firebase token is sent and my backend uses the uid field to look up firebase_id == uid to get the matching user in my backend or create if it does not exist. I would like to get rid of firebase_id and make uid be an integer so that instead of querying firebase_id I can query the integer primary key of the users table.
Is this possible?
Or are there any alternatives?
I want to do this for performance reasons, if that matters.
The UID of a user is determined by the authentication provider that creates that user. None of the built-in providers allow you to control the UID that is created, so you're out of luck there.
What you can do is create your own authentication provider and use that with Firebase. The UID is then under your control.
I know UID is used because it is unique. But in my app, all of them are registered with Google ID, Google ID is also unique. Should I use UID?
yes it is better to use the uid.
From the docs:
You can let your users authenticate with Firebase using their Google Accounts by integrating Google Sign-In into your app.
So after you authenticate the users, the uid will be in the authentication page in firebase. That id will help you later in the firebase database also and it is easier to use and add in the database.
Can easily be gotten using this:
FirebaseUser user=FirebaseAuth.getInstance().getCurrentUser();
Then you can use the method getUid() to get the userid. So using it will make the work easier for you.
From the docs:
After a user signs in for the first time, a new user account is created and linked to the credentials—that is, the user name and password, phone number, or auth provider information—the user signed in with. This new account is stored as part of your Firebase project, and can be used to identify a user across every app in your project, regardless of how the user signs in.
Also check this link: https://firebase.google.com/docs/auth/android/google-signin (Next Step section)
I'll suggest you use email ID instead of UID because if the user account is deleted from your Firebase Auth (either you delete it using Admin SDK, or perform a manual deletion on console), the next time user signs in with the same email ID will now give you a different UID and therefore all of your data in your database which rely on your UID won't be accessible.
However, you can't use use an email ID as it is, because Firebase key doesn't allow you to use . (dot) as keys, so just replace your . with a ,. You can find more information here.
TL;DR
Use email ID as it will always be unique unlike UID which gets generated every time a user signs in if that ID was previously deleted on Firebase Authentication server.
I want to have a username/password login system instead of email/password. What I am currently doing, is to take the username and append a '#domain.com' at the end and register the user on firebase as an email/password account.
In my firebase database, I am storing the user information under 'userProfiles/$uid'. However, given only the username of a user, I need to first access another node to lookup the uid and then use that to access the user data.
My question is: are there any disadvantages in just storing the user data under each username instead? In my security rules, I can then do this:
$username + '#domain.com' === auth.token.email
Most of the time, I have direct access to the user's uid. However, there is the case where I want to reset a user's password(I had to implement it myself because I am using the usernames as emails in firebase) and I only have access to the username.
Update
As pointed out in the comments since users are being signed up using username + '#domain.com' Firebase will prevent duplicate usernames because it won't allow two separate users to sign up with the same email. Once your user is created you can write the username to the database and there won't be any collisions. Keep in mind that this problem can become more difficult if users are allowed to change their username. You'll have to check the newly requested username against the existing usernames to determine if the requested name already exists. Lastly, don't forget Firebase is case sensitive so you might want to cast all usernames to lower/uppercase and trim the trailing white space before you upload them.
The biggest problem I can think of is that uid's are guaranteed to be unique by Firebase so there can't be any duplicates. If you store everything by username you'll have to make sure there are no duplicate usernames when users sign up. So you have to make an area of the database that can be read from by unauthenticated users to check the requested username against existing usernames.
You have to think about how you're going to access the data most of the time. Additionally, if you denormalize the user data (store it under uid & username) you have to make sure that both copies stay in sync. It's probably easier to just store username -> uid so that you have a mapping to get to the user data if you only have the username. This isn't going to happen that often and the extra nested query isn't going to make much of a performance difference.