I see that in Firebase deleting a user is very easy, but in my case I would like to prevent its cancellation so that the user can delete only his data in the database.
Why? Because if I maintain his uid and email, I’m sure that if this user wants to re-register with the same email, he will want to reuse the same data. In the case of old data that has not been purged, the result will be nearly the same without having to create another uid but with the risk of having dead account data lingering in the database.
Related
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).
I'm making an app that has Firebase as its database. The app shouldn't need the user to create an account to use it, but I want the user to be able to read/write their data onto the database (so maybe they have to create an account?).
Do I have to make the users create an account in order to use Firebase?
My problem is that my security rules are read/write are allowed for everyone (which I know is wrong, but how do I change them and not need users to create an account?) Maybe that's the issue.
It is best to ask them to create an account
Although:
it can be a non-real email address and
there is anonymous auth also available
It sounds like you need the app to remember that user's particular data, so that when they return to the app, it is still their data (and not someone else's) that is being accessed.
To achieve that, we need each person's data to be stored in a different place in Firebase. Traditionally, this is by having them log in to some kind of system, most conveniently Firebase itself, and then the data stored in a branch of the database defined by their user Id.
Without logging in, you could simply ask the user for an identifier, such as "Bob" or "Carol", and then store their data under their identifier. The Firebase database would therefore have the following structure.
users/Bob/highScore: 3000
users/Bob/level: 7
users/Carol/highScore: 5050
users/Carol/level: 9
However this is not secure because there is nothing stopping Carol coming to the app and saying she is "Bob". Any such client-side activity you carry out to attempt to identify the user is not really authentication (in the opinion of Firebase) because all client-side activities can be faked relatively easily.
Firebase Authentication
The standard solution is to use Firebase to authenticate each user (see the Firebase authentication docs for this), and give your app a user Id (such as "8769dsg6f8g7698769876sdgs9") which is unique and known (by Firebase) to be correct.
Firebase security rules
You can then lock down the database using Firebase Security Rules so that only user 8769dsg6f8g7698769876sdgs9 can write to any of the users/8769dsg6f8g7698769876sdgs9/.... part of the database.
If you don't use Firebase to authenticate the user, Firebase will treat the user as unauthenticated and you will have no way to restrict each user to their own section of the database. Either you leave it wide open (to hackers etc!) or users will not be able to access their own personal data on it.
They can use a FAKE email address and password
If your concern is that they won't want to give out their real email address, you can ask them to make up any email address, e.g. mickeyMouse49857430679304#hotmail.com, and set a password. There is no obligation on your app to contact them on that email address or verify that the email address is correct.
Whenever they come back to the app, or access it on another device, they need to remember the fake email address and password.
Of course, if they lose their password, there is no way to reset it.
Anonymous Authentication, but at risk of losing access
The legendary Frank von Puffelen of Firebase, himself, has added a remark about Anonymous Authentication, in the comments below. From what I understand, this avoids them having to make up a fake email address.
I think the weakness of this is that if they lose their local web storage (e.g. if they manually wipe it, or move to another device), there is no way for them to re-access the same account, unless they have planned ahead by adding an email/pw to the anonymous account.
The only real way to have security per-user data storage is to use Firebase Auth to sign in the user, and write security rules to protect the database so that each user can only access their own data. There are no secure alternatives to this for Realtime Database.
I signed up a user in my Flutter app using FirebaseAuth.instance.verifyPhoneNumber(). This works perfectly and the user shows up in my Firebase Console.
FirebaseAuth.instance.currentUser() now returns the user for me whenever I open the app. Should I store user info (age, weight etc.) here, or should I create a users collection in my Database and link the currentUser().uid in there?
Also, should I store it on the Database linked against the uid, or linked against the login info. For example, link a user to the phoneNumber and not the uid. Because if you ever delete the user, but they want to register again, then they will get a new uid, but their phoneNumber / email will still stay the same and can therefore still link to their old data.
You can't add arbitrary data to the Firebase Authentication user profile. So you should store the additional data in a database, and indeed associate it with the UID of the user, so that you can easily look it up. This also allows you to implement searches for users more easily, as the client-side Firebase Authentication SDKs have no functionality to look up data for any user but the currently signed in one.
To the additional question: if a user deletes their account from your application, you should respect their wishes and delete the additional data that you store for them too.
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.
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.