Yes, the order of operations does matter. It might be up to the business model, though.
If you require an email, then you should require the email to be:
Valid;
Real;
Unique;
Really owned by the user;
Additionally, if you want to restrict 1-to-1 relationship between user and email address, then you should also use a RegExp to filter out infinite gmail address combinations — otherwise any user will be able to register an infinite number of accounts.
If you require #4, then you must send a verification email. In that case, the order of operations is as follows:
User submits form with all data including email;
If email address MX record doesn't exist > validation error;
If normalised email address already exists in DB > validation error;
Create user in DB, generating confirmation token (hash) and timestamp;
Send confirmation email to the user;
Assuming you require an email, you shouldn't allow the user to do anything a logged-in user can do until the user clicks the confirmation link. URLs for restricted areas should be different.
Thanks for your comments, Carlos. I think I have less risk of people creating infinite accounts with my current project because it is a paid service. However, I like the way this is laid out. What do you mean URLs for restricted areas should be different? I have basically a concept of domain/actuallstuff/:userid and the route to actuallstuff checks that user is user with userid - If you meant something else, I really want to know!
Sorry for the confusing remark. What I mean is that it is cleaner and safer if domain/actualstuff is only accessed by logged-in users. If you want the world to see similar information, make it domain/almostactualstuff
Yes, the order of operations does matter. It might be up to the business model, though.
If you require an email, then you should require the email to be:
Additionally, if you want to restrict 1-to-1 relationship between user and email address, then you should also use a RegExp to filter out infinite gmail address combinations — otherwise any user will be able to register an infinite number of accounts.
If you require #4, then you must send a verification email. In that case, the order of operations is as follows:
Assuming you require an email, you shouldn't allow the user to do anything a logged-in user can do until the user clicks the confirmation link. URLs for restricted areas should be different.
Thanks for your comments, Carlos. I think I have less risk of people creating infinite accounts with my current project because it is a paid service. However, I like the way this is laid out. What do you mean URLs for restricted areas should be different? I have basically a concept of domain/actuallstuff/:userid and the route to actuallstuff checks that user is user with userid - If you meant something else, I really want to know!
Sorry for the confusing remark. What I mean is that it is cleaner and safer if domain/actualstuff is only accessed by logged-in users. If you want the world to see similar information, make it domain/almostactualstuff
Thanks for clarification!