I would like to know which procedure should I take in the following situation:
A user register itself into the system and an email is sent to confirm the account (with the confirmation token).
But the user doesn't comfirm the account...
If later, the same user or another user try to register itself with the same email, should I:
Delete all the information about the first user, create an entirely new account and send a new email for validation?
Change the existing account by reseting the password and send an email with a new confirmation token?
Another suggestion?
In this scenario, I'd say that registering an account is like putting down a deposit. You've basically staked a claim to that user account. I would give the confirmation tokens an expiry time - say, three days or so. If a second user tries to register an account that conflicts, check whether the user it conflicts with is verified, and for unverified users, check whether their token is expired.
If there's a verified user with that name, tell them "sorry, that username is taken".
If there's a user who has yet to verify...
If their token is expired, then delete it all and give the new user the name, generating a new verification token for them.
If their token is still active, then the new user can't have the name. It's up to you whether you just say "that username is taken" or maybe let them know that it's not verified and may be up for grabs sometime soon. I'd probably avoid confusing the users with that much detail, and just say it's taken.
Related
From the documentation I could find out that only upon first login into my app, the users name and email will be returned with the credential. So i go ahead and save these to my backend.
Now if the user decides to delete his account, I delete all his data from my backend (thats propably what the user wants me to do. And isnt that what i have to do anyway according to some privacy laws or what not?).
Now if the user ever decides to change his mind another time and install the app, will i not be able to fetch username and email? No matter what i do? Or did I miss some kind of user.ultimateSignoutAndDelete(for: .ever) to be able to fetch userdata on his next sign in?
Maybe this scenario seems a bit constructed but when testing apple-sign-in you stumble upon that immediately.
Once you delete a Firebase Auth account, there is no way to recover any information from that account. All links between the user and your projects are gone. The user will have to create a new account.
Firebase Authenticaiton allows users to sign in with a provider, like Google or Facebook.
However, if the user has never signed in before with a given provider, a new user account is generated for them automatically, and they are immediately signed in.
This is problematic for two reasons.
First, the developer may want to run some code on the server before the new user is signed in, such as preparing documents in the database for the user.
Second, the user may previously have signed in to the site with a provider account, but cannot remember which one they used. If the account they choose to sign in with has not been signed in with before, it would be useful to display a confirmation dialogue to the user to confirm that they wish to create a new account in the site. In some cases, the user may decide not to, and may try another account, to find the account they previously logged in with.
So, is there a way to have the user go through the usual OAuth flow, select a user to sign in with, determine whether they have signed in with it before, display a confirmation if they haven't, and then, if they confirm, create the user, or if the account already exists, and sign them in?
So, is there a way to have the following flow?
User chooses an account with the usual Google OAuth flow.
If the account is already registered with the site, it signs in.
If the account is not registered with the site, the user is asked to confirm that they wish to create a new account.
If the user wants to create a new account, the new account is created and other operations are conducted on the database, like preparing certain database documents for the new user.
Once the new account is created, the user is signed in to it in the browser.
Yes, the sign in methods return a UserCredential object, which contains AdditionalUserInfo object. You can check isNewUser attribute from additionalUserInfo object.
I am very curious to know some of the points regarding registration and login related points as a developer points of view. Please see below the steps for any online account which is publicly open for all,
CREATE USER ACCOUNT : Insert the data entered by user along with a column activate which default value is 0
SEND A LINK TO ACTIVATE : a link has been sent to user email at the time of registration
ACTIVATE THE ACCOUNT : user clicks over the link and the link is verified and update the column 'activate' with value 1
Why to sent a link & verifying is necessary which I supposed that is not utmost required. I asked to clients why u want such verification and i get the answer almost same e.g. checking the authenticity of the user and it'd be helpful to stop the duplicity of the user.
but practically at the time of user login, i suppose it is useless to verify each time the activate column along with password for every user.
I would appreciate if u explain the points which is very important regarding my concern.
This is really a slippery slope, but there are reasons. Obviously spam users will try to create accounts as quickly as possible, for spam reasons. Email and captcha verification will handle this.
Another is the issue of clumsy or accident-prone users that will forget their passwords, which can be worked around by email reminders/resets. Sadly, users may try to add fake email addresses(or mistyped ones) and lose access to their accounts, requiring admin intervention. Simple verification can force users to get their account into a self-rescuable state before adding any data.
I am brand new to Visual Studio 2012 and MVC 4, and I've been working with the SimpleMembershipProvider via the WebMatrix.WebData library.
I'd like to integrate Facebook as an external login source down the road, but it's not a requirement as of right now. However, to get a decent feel for what it would take, I've been following the tutorial and guide found here - http://www.asp.net/mvc/tutorials/mvc-4/using-oauth-providers-with-mvc.
My question :
If a user has already been created using :
WebSecurity.CreateUserAndAccount(model.Email, model.Password);
WebSecurity.Login(model.Email, model.Password);
Can they be "upgraded" to an oAuthMemebership account in the future, if they choose to use their Facebook credentials instead of the email and password they created when first signing up?
I couldn't find a clear answer to this question in the guide, or elsewhere, so I'm hoping someone can clarify how that process may work.
The SimpleMembership setup allows for a local and multiple OAuth logins all sharing the same UserProfile - so a single user can login with either a local password, or FacebOogLiveWitter.
(I should state, that I'm assuming in this answer that the OAuth provider does not send back a matching piece of information for a local account. If they do then the principles of actually performing the merge are the same, but the complexity and steps are vastly reduced.)
The OAuth registration process will refuse the user if they use an existing user name, rather than try and merge two accounts. Therefore this isn't simple, you'll have to build the functionality yourself. The process is complex as there are many directions the user can approach this from (so you could simplify by only supporting one or two), and you need to enforce security as well in case someone tries to merge into an account they don't own.
I will assume you are comfortable with the link you've posted, and you've followed the Facebook help at (for example) Facebook Login and The Login Flow for Web (without JavaScript SDK) so you have a working test application.
Your general process has to have multiple user journey approaches to make sense to a user:
for a logged in user (with a local account)
let them login to facebook and associate the accounts
let them merge an existing account on your site which uses a facebook login
for a logged-in user (with a facebook account)
let them create a local account
let them merge an existing local account on your site
for a non logged in user who tries to register a local account
let them merge this new account with a facebook login that is already registered, and do that as part of the registration process
for a non logged in user who tries to register (or log in for the first time with) a facebook account
let them link this with an existing local account as part of the registration process
etc.
ASK PERMISSION
(You can skip this if the OAuth provider has sent back a matching identifying piece of information, such as an email address).
You should enforce confirmation security, usually through email confirmation sent to the target account of the merge. Otherwise:
someone can login to your site with facebook for the first time
during that process say they "own" the email address or username of a local account (remember, facebook won't necessarily confirm what their email is for you)
and therefore gain access to the existing local account
So, once the merge "request" is made, you need to ask for permission to proceed from the target account of the merge.
The MVC 4 AccountController
I will use Facebook as our OAuth example. To compare what happens when you register a user on your local authentication framework vs. OAuth:
Local: creates an entry in webpages_Membership and an entry with the same UserId in UserProfile (assuming you are using the default tables for the MVC 4 application template)
OAuth: creates an entry in webpages_OAuthMembership and an entry with the same UserId in UserProfile
Now let's look at what happens when a user signs in using Facebook for the first time:
They click on Login using Facebook (or whatever your button says)
they get taken to facebook to login
they succeed (let's assume that, and ignore the failure case)
they then get sent, invisibly to them, to /Account/ExternalLoginCallback
OAuthWebSecurity.SerializeProviderUserId is called, passing the OAuth details to that Action
They get redirected to /Account/ExternalLoginConfirmation and asked to provide a username for their new presence on your site
If that user name is available then UserProfile and webpages_OAuthMembership entries are created
This process is your chance to "join" the accounts by matching some unique piece of information. As long as you end up with the same UserId in UserProfile, webpages_Membership and webpages_OAuthMembership you should be ok. So we have to intercept the process at the point of /Account/ExternalLoginConfirmation.
If the OAuth provider has sent back a matching identifying piece of information, such as an email address, this becomes simple, test for this in the ExternalLoginConfirmation action, and auto-merge using a similar process to the one outlined below.
However, I think you can't/shouldn't assume that the user uses the same email address for your site and OAuth, (nor should you for many reasons). Also, probably in the T&Cs for something like FacebOogLiveWitter it stops you asking for the email of their account anyway, and if they don't currently they might in future.
So instead, you could link the accounts based on alternatives, like username or email address, or phone number. Either way you are going to need them to input some identifying piece of information that is unique against an account, and will pull back the target account.
Wrapping up
So to put this all together: In the first part of this answer I outlined how you will need to consider multiple user journeys to merge accounts. I will use the example 4.1.
Your process will need to:
(Assumption - when a user first registers with a local account, you ask them for an email address and validate it or assume it is valid)
Let the user login with facebook for the first time
at Account/ExternalLoginConfirmation ask them if they want to
Create a new account with you
Use their facebook login to access an existing account
Assuming the latter, then you log a request in a new table (maybe "MergeAccountRequests") with:
The facebook account UserId
The target merge local account UserId
An authorisation code to use in the email you need to send
(From this point on, if they login without confirming that merge, they will have to get sent to a page to ask them to confirm, rather than create objects in other db tables which you have to worry about later)
You then send an email to the address of the target merge (local) account asking for permission to complete the merge (a standard confirmation email, with a link)
When they click on that link, or enter the code you sent them (you could use SMS as well as email) then you need to merge the two accounts
Choose the "new" and "target accounts (in this case "new" is the facebook account as you don't have data associated with it yet)
Delete the UserProfile of the "new" account
Change the UserId of the "new" account webpages_OAuthMembership table to the same as the "target" account
Log the user out (so there are no complications depending on which account they are currently logged in with)
Display a message to the user telling them the merge is almost complete and that they can now log in with either account to confirm and complete the merge
Rather than send them to a login page, i would give them the login options alongside the confirmation message.
Is it safe to login user automatically after registration?
User fills registration form, some info message is sent to his mailbox, and what then:
User redirected to login page asking him for credentials;
OR
User auto-logins as his newly created user?
I feel something not safe enough in auto-login, but can't figure it out!
If they just filled out the login information and you're not concerned about confirming that the email address is legit, then there shouldn't be a problem just logging them in directly.
However, you open yourself up to people/bots creating bogus accounts (at least ones without legitimate email addresses). If you're concerned about that (not sure it this is a public facing app or intranet, etc) then you should at least verify the email address by sending a link with a guid or some identifier that you can track back. Then you can let them log-in once they are confirmed.
You could also just tie it to their StackExchange/Facebook/OpenID/etc account and not make users fill out yet another form and worry about maintaining all that information.
They should need to login. Also the confirmation email should not contain their password. If they managed to give you the wrong email address and you automatically log them in then someone else has access to their account now. This holds even if you have them type their email address twice. Sometimes people make the same mistake twice in a row.
It can be safe to auto login if the user already has an active session as the correct user during the confirmation step. If you think about it, it's not actually "automatically logging them in" but simply keeping them logged in as they was before.
User registers
Keep a session identifying the user
User navigates to the confirmation page (linked in email)
You activate the account
During all that time, there was no reason to end the session. The only reason you would want to end the session (or not create one in the first place) is if your permissions are not properly set to allow someone to login / create a session without giving them higher privileges than an unregistered user.
Now, be sure not to automatically identify the user as X simply because this person navigated to the confirmation page of user X. If a user navigates to this page but does not already have a session open, do not assume he knows the password.