I have a flutter app using firebase and google cloud. The organization providing the app to their users uploads a list of users that are able to register and create an account. When a user goes to register I want two things to happen:
They are given an error message if their email address and ID number do not match an existing document with email and ID field values
Existing fields, like their department and deck number that are in the collection uploaded by the organization are copied to their new user profile
I would write a cloud v2 function. The documentation has some great examples of how to block registration. What you would want to do is in the beforeUserCreated method, look up the field in firestore to validate that their email. You can get their email through the AuthBlockingEventType additionalUserInfo field which should provide the username (email in this case) to compare against the firestore database.
Deploying an AuthBlocking function is the same deployment as any other function.
Once deployed, you will need to remember to register your blocking function for it to take effect.
As far as updating their user profile information, you could just use another cloud function to listen for a database change once the user is registered and then copy that data over.
Related
I am builing a flutter firestore app in which I want to be able to send a referral code to a new user and per referral code only one new user should be able to join.
Please tell me how can I implement this in in flutter app.
Thanks.
You can generate them with function you like, store them as documents in separate collection (document name is referral code - this will give you uniqueness of codes) then when user uses it you write his auth id in special field. Then in security rules you make rules that field may be updated only if there is no id there already.
I would like to use Stitch to sign up users. Each user must have a unqiue email and a unique user-name.
This is important for applications like chats or forums, where users should not be forced to reveal their email when communicating.
I already implemented login with email and password as described here: https://docs.mongodb.com/stitch/authentication/userpass/#authenticate-a-user
The problem is:
How to securely save a user-name on signup? I could store a users desired name in a collection and merge it into his custom user data after initial login. In order to do that, I would need to grant the user write privileges to whichever collection holds pending names. This is unsafe, since he could now change the name after the fact or even change other peoples names while they are pending.
The user needs to choose his name at the time of signup. At this time the user is still logged in via anonymous credentials. Hence, I can not restrict users to changing only their own data since they are at this point sill anonymous. I see no way of linking a users data to his future account at the time of signup. Any idea to change that?
It would seem strange, if stitch lacked the functionalities to easily sign up users with a unique name/handle in addition to email address.
I haven't used your exact software but in general I would approach the problem as follows:
When someone starts using the application anonymously, create a user object. The user at this point does not have a reserved (i.e. globally unique) user name, or email address, etc. But the user still has an internal identifier.
Associate user-visible state with the user object. This could be done through server-side sessions or signed cookies. (Unlike unsigned cookies, cryptographically signed cookies permit server to store what would otherwise have to be stored in the server-side session in a cookie, and trust that the client hasn't tampered with the information by e.g. changing the user id).
When user registers, set the user name, email address, etc. on the existing user object. User id remains the same and allows the user to continue to have access to their anonymously-generated data.
Have a process for deleting anonymous users that don't register after some time.
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.
I have an existing website in MVC4.
Now I am looking forward to upgrade it to MVC5.
I wanna use External Authentication, however, what I want is that when use select any of the External Login option (Except Twitter, I am not going to use it), all I want is to get his/her Name and email address.
I don't wanna store anything in the database with the username or other details associated.
I just need to grab the Name and email address and if it matches with existing email, user will be logged in, otherwise, new account will be created.
It will be great if anyone can help me with this with small tutorial, to read Name, email and other extra details from the user, instead of adding it to the database.
Currently on my website, users login with their login id and password, they are also required to enter their email when they register. Both login_id and email column on the users table have unique index. users table also stores other data associated with the user such as gender,last_name,first_name but these are optional (nullable) fields.
There are two changes I would like to make to the website.
The first one is, users can use their email (in addition to login_id) to login. For new users, when they register, they no longer need to provide a login_id because they will be using their email to login.
The second change is, they can login with facebook. For new users, if they login with facebook for the first time, their facebook uid will be obtained and stored in my database. This means I will have to add a facebook_uid column on the users table.
For existing users, when they login with facebook for the first time, I should first obtain their email address from their facebook profile and then check if there already exists a record using that email in the users table, if yes, their facebook uid will also be stored on the facebook_uid column on that record.
According to facebook, its platform supports two different OAuth 2.0 flows for user login: server-side flow and client-side flow. Which one or both is required for this use case?
Also, what problems can be anticipated when I implement the features like I describe above?
You could take either approach for this, it's entirely up to you. Both methods will give you the data you need, it's a question of how comfortable you are working on the back vs front end. You just need to ask for permission to access to the user's email address.
Problems that could happen: I'm not sure but there may be legal restrictions on storing the user's Facebook ID. Also, what if someone (not me, an evil person!) registers with my email address and you don't validate that they really have access to that address - then when I log in via Facebook, the app will assume we're the same person and the evil hacker now has access to my account. Unlikely scenario but could happen...