I want to alert users who are registering that their choice of email address is already in our userbase; how can I compare their (desired) email to the users in my user list before (while) they register? Where exactly are the users stored and how can I access taht datanode?
You should have a users node that contains your users and other info about them.
Login credentials are stored internally in firebase so you don't have direct access so them. Having a users node allows access to other data about the user (and can double check to see if an email address is already in use).
users
uid_00001
name: "Frank"
email: "frank#wazmo.com"
fav_movie: "Airplane"
uid_00002
name: "Kato"
email: "kato#yipee.com"
fav_movie: "Pink Panther"
Using the above structure, you can simply query for the email address and if there's a match don't allow them to use it.
This is very common practice and there's a lot of information about handling users on the Firebase website.
Check out Storing User Data in this link
https://www.firebase.com/docs/ios/guide/user-auth.html
Note: 7 years later... When attempting to create a user with an email that already exists, Firebase will return an error indicating the email is in use, to which you can handle the error in that fashion.
That's probably a better option than querying a users node per above as that would require giving access to it for unauthenticated users.
Related
I am trying to determine if the following scenario is possible with flutter and firebase:
we have users within the company who will be given access to the app, where on the homepage will be a signup another user button where they enter in that user's email and password, they get signed up, and then the original user specifies custom fields for the 2nd user, such as company name, role, position, etc.
Is this possible with flutter and firebase?
Have asked the flutter google group and was told about custom authentications, but from what I see that is just an external authentication system and doesn't show me how to let one user create another users profile with fields.
Any ideas?
The first thing to consider is whether those properties need to be in the user profile at all. The user profile is sent with every request, and should only contain information that is relevant for securing access. If you have additional information to store about the user, you should store it elsewhere (such as in one of Firebase's databases) using the UID of each user as its key.
Assuming that the information is about security (such as the role seems to be, there is no secure way to let one user set security properties (typically referred to as claims) from client-side code. As soon as this is allowed from client-side code, anyone could set such properties for anyone else. That's why setting custom claims for a user is only possible with Firebase's Admin SDKs, which are designed to run in a trusted environment - such as your development machine, a server you control, or Cloud Functions.
There are a few other options, but it's important to realize they're all implemented on top of the above approach.
There is an experimental extension that allows you to set auth claims by writing a document into Firestore, which something like this (JavaScript syntax, but the Flutter code will be similar):
db.collection("user_claims")
.doc("abc123")
.set({
role: "admin",
groups: ["example1", "example2"],
});
Now of course you'll want to make sure that you secure writing to the user_claims collection, as otherwise you'll end up with the same security risk I mentioned in the first paragraph, where everyone can claim any role they want.
Alternatively you can write your own server-side API (for example on Cloud Functions) that you expose to your application, and that then calls the Admin SDK. Here too, it is important to secure access to this API, to ensure only authorized users can call it.
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 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 am making a social media site. I want to authenticate and verify people's accounts with their emails. I also want them to log in using their email, but I don't want to be able to see my users' email addresses because I want them to have privacy. Ideally, they should each just have a userID and their email will be associated with that userID, but I won't be able to see it.
Still, I want the ability to ban people by userID, and then for their associated email to also be banned from my social media, but I do not want to know whose email I just banned from my app. Basically, on this page, I would prefer if it did not tell me what my email was:
I'm using the very basic code to sign up users:
Auth.auth().createUser(withEmail: email, password: pass
How might I modify this code?
It sounds like you want some sort of application-specific administration console for banning users without knowing their identity.
There is no way to change the display of the list of users in the Firebase Authentication console.
The most common approach is to build the needed application administration functionality yourself using the Firebase Admin SDK, and then expose that to the application administrators.
As #Frank van Puffelen said,
You can't change the view of Firebase console. and it will show you the email,userid and some basic information always.
How do you know the UserId of people? for getting userId in some cases, you need the email id.