How to login a new user by default after mail Invite in Meteor? - meteor

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

Related

Set password and verify email in one step

Lots of questions about email verification here on SO, but none seem to cover my scenario.
We would like to add users ourselves after an intake meeting. Our representative has a form to enter some details like company name, VAT number, contact data (which contains an email field), ... This data is saved in Firestore.
After this, an email is sent to the supplied email address which contains a link that takes the user to a form where his/her email address is displayed with a password and a password confirmation input field. When submitting this field, the user is created.
But now the user receives an email asking to confirm their email address. I assume, for security and privacy reasons, there's no way I can set the user's email address as verified.
I've looked at customizing the verification email, but that doesn't seem to solve my problem.
Creating the user with a random password after the intake meeting also doesn't seem to be a solution, as the user still has to verify and then reset the password in 2 steps. Or can I somehow redirect after the email verification to the 'set password' page? That would be an acceptable solution.
Is there any way to achieve the desired flow described above?
As a general workflow, you could achieve this using a Cloud Function along with either database system. You can also make use of App Check to further secure this process.
Representative adds base user information in their portal. Store the data securely in the database of your choice.
Send the user an invite email containing a short-lived verification token linked with the email added by the representative (this could be generated and fired off using an onCreate Cloud Function once the invitee's data is added to the database). This token should follow some standard like JWT so you can deserialize the contained email address or be exchangeable for the underlying email address.
When user clicks/copies the link to their browser, present them with an input form asking for the desired email and password. Note: the email field should be editable! The rep may have used an email the new user doesn't want to use with your platform.
If the token is still valid and not consumed, continue with the next steps.
If the token has expired and not consumed, send another email to reconfirm their email and restart this step.
If the token is already consumed, show an error and don't continue.
Submit the email, password and emailed token to your backend via a Callable Cloud Function.
Sign the user in using the authentication token returned by the function on success. Show an error otherwise.
In the callable function for creating the user:
Confirm the request comes from your app (if using App Check)
Confirm the validity of the emailed token
Pull the data the representative entered from the database linked with the emailed token's original email address.
Using that data, the updated email, the new password, and emailVerified=true, call the createUser API.
Using the User ID from the returned UserRecord, create the user's profile data in the database and also create a Custom Authentication Token.
Once their data has been created and the token generated, return the authentication token as the result of the request.

Firebase: Securing records by email address when users can use fake addresses

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.

Validate the Authenticity of a User For Site Subscriptions

I have a web application that creates user accounts, but I would also like to have the ability to have users that can sign up for subscriptions without accounts. All they have is a subscription page to modify email settings and enable the newsletter subscription.
My questions is how do I verify that the user is who they say they are without a username/password, and my second is how should they access this page. I dont want just anyone typing in the url with the email and access subscription settings for that user.
For each user entry you create a unique access code that you use in the url in order to validate that this is the user you want.
The subscription form will give these options:
subscribe by filling in your email
request to change your settings by just putting your email to another field
both action will send an email to you with a special url
the first to validate that this is made by you so you will enable this user & his email
the second to send him another special url to make any changes to his settings in the case that this use is active in your database.
For this unique code you can use md5 of his email with a timestamp when he was registered.

Designing an new user confirmation (verify via email)

I am developing an ASP.Net application that will need to verify that the user is legit and not a spam. Once the new user enters their first name, last name, email address, my application will send an email to verify the user's authenticity. The email would conatin a link that would confirm the users account.
I am looking help on what the logic is behind the email link. Once the user clicks the link, what happens?
I have had a website that has used Captcha, and not had much luck stopping spam (I know you can't stop 100% spam) similar to this Stopping spammers from creating accounts (reCaptcha not doing the trick)
As Rook has pointed out below, the simplest way is to use Captcha.
If you need to verify the email as well though, see below.
You could generate an approval GUID and pass it to the email URL which would mark the User as Active.
For example, add a column called ApprovalID to the users table and generate a new GUID when the user registers, i.e.
You should mark the user as inactive at this stage.
Example Guid 3F2504E0-4F89-11D3-9A0C-0305E82C3301
Then pass the User Id and GUID in the email body
Verify your account
Then a simple page verify.aspx
Code Behind
string UserId = Request[UserId].ToString(); // You can parse these as Guids
string ApprovalId = Request[ApprovalId].ToString();
TODO:
// Get user from database
// Match QueryString ApprovalId to Column ApprovalId
// Ask user to Log In
// Set user as active
Sending a confirmation link doesn't do anything to stop spam. Emailing someone a link with a Cryptographic Nonce just insures that they can receive email, bots can also receive email.
The best way stop spam is by using capthca, and I recocmend using reCapthca. You should prompt the user with a capthca when a user signs up for your service.

Securing temporary passwords sent through e-mail to users?

I have a simple web application set up where admins can create users. Users do not create themselves. All an admin has to do is enter a username and an e-mail and a temporary password is sent to the user for them to login. This e-mail is sent in plain text format. If the user is logging on for the first time, they are required to change their password and enter a security question and answer. The user obviously has to know their temporary password in order to login for the first time and this is the only way I know of letting them know (through e-mail). The other option would be to have the admin call the user and tell them over the phone or in person their temporary password, but this is not practical. How could I handle a situation like this?
I typically use a temporary url based on an invite record on the back end. Essentially you create an invite record and generate a hash based on some information perhaps the users email address, a timestamp and a random value. Store the hash as part of the invite record and then send them a url with the hash as the parameter.
When they click the link lookup the invite and validate that it exists and has not been used - then allow them to setup their password and invalidate the invite.
It gets rid of the need to send any sort of password and you can set an expiry on your invite records if you want as well.
The scenario you describe is very common- emailing a temporary password and requiring it to be changed on first login. Unless you have a specific problem with this model I see no reason not to use it. Having an admin call users can get complicated- I would avoid this at all costs.
You can generate a custom url with a password and user hash as argument where the user has to log itself. The hash will be difficult to retrieve if the attacker does not have the information

Resources