So I'm making this app for pharmacists and their patients. Pharmacists can manage their patient's data through the app - and most importantly sign up their patients to the app.
The ideal flow goes like this - at an appointment, pharmacist gets patient's email address. Pharmacists can then create a user account, either setting a password right then for the patient, or sending an email letting the user set one up.
Is there anyway for one user to create an account for another user within firebase?
Cheers
As long as its at a manageable rate as you could hit quota limitations.
The pharmacist can create a new password account with the email provided and some random password and then trigger the reset password flow. This will send a reset password link to the user.
You can then build a custom landing page for resetting the password where the user would take control and finish setting up their account.
Check the docs on building custom email action landing pages:
https://firebase.google.com/docs/auth/custom-email-handler
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'm currently building a POS/Store admin app, when a user gets into my app, the Owner of the store will then be asked to login only once for setup purpose (e.g. a new machine), the app will then display a list of staffsName that has already been added by this owner, and then everytime a staff wants to start a new transaction, he/she will only need to click on his/her name, then enter his/her 4-digit pincode to 'login' and process the transaction.
How do i go about achieving this?
I was thinking of using firebase auth for the 'login' of the staff, but then when i log in using the staff credential, I will lose access to the uid of the owner, which is needed to access the owner's store data such as his/her products.
i'm also thinking of using firestore to store the 4digit pincode, but then i'm also concerned about security
There are multiple ways you can approach this, one where you utilize the email login by simply appending a fake domain to the username to create a valid email domain. This user account could be the designated 'user' in question, or utilize credentials inside custom claims or hidden in a database that allows the client or server (depending on your preference) to then log in as the user.
Moreover if you want the manager to login once you can add Authentication State Persistence to specify whether a signed in user should be indefinitely persisted until explicit sing out, page reload etc.
Another approach requires the user also to have a valid auth that is not an email password and you link your pin auth to that main account with Firebase Auth Linking per the documentation: https://firebase.google.com/docs/auth/web/account-linking.
This does however require that the user be registered from an auth provider such as Google, Twitter, Apple, etc. then the user will have to activate this link by logging in for authentication purposes. This can in theory be automatically generated and processed without the user knowing.
It is a long way around it since this is essentially a custom solution but it does create the flow you are looking for without having to use a custom auth provider.
I am developing an invitation mechanism to our app. New users will be invited with their e-mail addresses or their telephone numbers. I would like to keep some records about the invited but non-registered user. So, I want to have their Firebase Auth User UID before they even signed up. Is this possible? Maybe using Firebase Admin SDK?
I don't want to use their e-mail addresses or telephone numbers to refer to them because UID feels like a better identifier. However, UID is not there before they sign up, right?
We toyed with creating a user and generating a passwordless login for them, etc. But whatever we do seems to mess with the initial sign up of users. It would be great if we could just get a UID and let the user sign up later.
You cannot create a user account, and then have the user "sign up" with the same UID. So you will have to handle your "sign up" flow a little differently.
In this demo an administrator creates a user account, and then invites the user to sign in by sending them an authentication code (jump ahead to the 3:00 minute mark in the recording). Then the user is allowed to sign in and activate their account by presenting the authentication code.
You can try to build something similar. For example you can save a flag for each new user in the database, and then clear that flag in a custom sign up action.
I'm making a web app where you pay to use it first and then sign in. The sign up workflow is this:
Once a payment is made on my website, the client receives an order ID that is associated with their email address. The client sends this to a Firebase Function endpoint to activate their order.
The Firebase Function checks the order ID is valid and creates a Firebase user with a long random password (to prevent anyone from signing in), then sends a password reset email. A "payment" record is created in Firestore and associated with the user ID.
The user follows the password reset email then logs into my app. The paid features are activated if Firestore contains a payment associated with that user ID.
This all seems fine except:
A malicious user Bob could outside of my control creates a user for email "x#example.com" that he doesn't own and sign in using the Firebase client SDK.
Alice then makes a payment for her email "x#example.com".
Bob will still be signed in and can now use the features Alice paid for.
How do I prevent this?
One idea I had was the above Firebase Function could check if user "x#example.com" exists with an unverified email address and if so it would 1) delete that user and 2) create a user for that email address again (creating a new unique user ID). Bob would then have a different user ID than the one associated with the email address so couldn't access the payment record. However, this breaks if Alice makes two payments without validating her email after the first payment. What's a robust way of solving this?
Consider verifying the email before processing the transaction.
One option is to use sign in with email link. This will sign in the user and verify their email. You can also set a password after if you want. If an existing unverified provider is linked to the account, it will be unlinked and any existing session that a malicious user had previously set up will be revoked.
I have a requirement where I need to log in a new user to a Meteor application by default, and take the user to the reset password route after that.
I looked into this documentation, but I don't think it would apply here, because the password is not known. Here's my use case in detail :-
A user invites another new user by providing the invited user's email ID. The application sends email invite to the user, asking them to be taken to a route which normally requires logging into the application.
The new user who receives the email invite, is not yet signed up with the application. So, they need to pick a password to log in to the invited area of the application.
Currently, I am using the meteor-useraccounts:core package; to trigger the resetPasswd route for FlowRouter. Using the onSubmitHook, one can redirect the user to the proper location after successful reset of the password.
However, I am not able to figure out how to first log in the user automatically. Because if the user is not logged in, the reset password page won't open. Instead, it would show some error, indicating unauthorized action.
How could a link be sent via mail to the invited user, which would automatically log in the user?
I looked into this documentation, but I don't think it would apply
here, because the password is not known.
That is right, and because of that, in order to achieve that you have to create an account for that e-mail at the time the user enters a link sent by e-mail. Or create the account at time of invitation.
So possible solutions:
1) create an account for an e-mail provided in query (http://app/login?email=blabla#google.com) for a route, random password, reset password e-mail sent immediately after the login. (create login automatically login the user). That would also required some security key, so that no-one could create lots of accounts on different e-mail addresses.
2) create account at time of invitation, take random password and send it as a query parameter of the link sent to the invited user. When user enters the site, you take that password (and e-mail) and login him with that, and immediately send reset password for that e-mail