Let's say we have a system that needs to validate data using a third party system. For example, we allow user registration and we validate the provided email address using an external system that tell us if the email is valid, if it is a temporary email etc, etc.
Our system receives the email address, makes a request in real time to the third party email validation system and, depending on the response (email valid or not) it will allow the user to register.
My question is: What happens if something goes wrong with the connection? (timeout, DNS errors, etc). I think it will be wrong to allow the user to continue the registration process because we don't know if the email is valid but, at the same time, we can't stop the registration process because the email might be valid.
I'm thinking in trying the connection more than once (let's say, three times). If it fails, then return an error code with a message like "Please try again later". Is this the right approach to this problem?
Thanks in advance :D
You treat this the same way as if any other sub-system on the server failed, e.g. the database being down: 500 Internal Server Error or 503 Service Unavailable. Whether you want to try more than once before giving up is up to you.
It all depends on what kind of system you are working with. If you are confident that the Users will definitely comeback to your site later and register this approach is fine.
But in Today's world there are so many web services out there and the users are great assets, you wouldn't want to loose them or their data. You can always collect the data and store it in a staging table and later if you can run some Schedules tasks every 5 mins or add them to a queue service to validate the data with this 3rd party and finally store it in appropriate way and send them a notification about their account being active. This way the User experience when they use your web page will be great and they would come back (a second win is you can actually verify their email account)
I'm designing a user registration form and am working on sending a confirmation e-mail. The script that is responsible for adding the username/password/e-mail address etc. to the database is getting rather long and I wanted to break the code responsible for e-mails into another file. I was thinking about how the two scripts would work together; would the database script include the e-mail script or redirect to it and pass the arguments. Or do I have it backwards? Would it be the e-mail script including/calling the database script?
What happens first? Does 1) an e-mail containing an account activation link get sent out before any data is added to the database or 2)is the data put in the database right away with an "activated" field set to false and when the user clicks on the link in the e-mail the field will be updated to true 3)or some other way?
#2, this is so that other users don't take the username twice. If you don't save the information instantly, then other users can also activate their account and you'll have errors with that.
Most websites have an expire on their activation so that the usernames can't be held for a long period of time.
A column for state such as user/banned/confirmed/unactivated would be necessary to keep track of who has activated and who has not. A cron job could be used to sweep the database for old inactive users, basing on the timestamp of registration.
Every system I've worked with has just stored the user in the database until it's used, but when spam becomes an issue you can look at other answers.
You need to store the username and password somewhere and sending it in the email is going to cause issues, and otherwise the link you give the email won't know which user to activate, and doing wacky things like storing it in the session is going to cause many, many ux issues.
Other than creating a second table for un-activated accounts, and searching both for the two different calls you need to search both (creating new user/email, and changing username/email), I don't see a better solution.
What I'm trying to do is creating a page to show my accounts balance. I got a bit sick of logging into my bank accounts using username and password since I've got two different with (luckily) very long/twisted password. So I want to code this self-login and then show the balance. That's it. No money transfer, nor payments.. Just the balance! But I thought it was a bit easier.. I mean, I know it's a bank website so it must be secure, but if I login remotely (let's say I'm able to make it) giving you my credentials, why don't you work? Why you just work on your own server? I know ssl, https, verisign, etc. But do you think there's any way I can do this? Of course there are no API's for third party developers, I have to find a way myself.
So this is what I did: I tried to log into the first bank account "remotely" (let's call bank.com the bank website). So if the page bank.com/login has a form with username and password, I made a localhost/login page that looks exactly the same. In fact, the action is the same as well, so after logging in I will be redirected anyway to my bank account (i.e. bank.com/dashboard). Simple? Not really.. There's a hidden field, a token, which changes every x time. So apart from what I did already, I should be able to add to my form this field as well. I should simulate this process from localhost: go to the bank website, enter the login area, browse the form, find the hidden field (token) and take note of it. Then add it to my localhost form and, eventually, log in from there. Well, the login area on bank.com is under https protocol so I can't access its content. My plan epically failed. Or not? I tried using file_get_contents to flush the bank.com/login content into localhost/login page, but it doesn't work. It looks like it's protected (verisign) cause the page is loaded completely, but part of its content is not available as it shows Error 500: java.lang.NullPointerException. I guess it's part of the verisign handshake, so the content is available just after this process. Do you have any idea? Should I give up instead? :)
Most of the examples I see on the web create user accounts in this sequence: user comes to the site, they choose a username and password and enter their email. A confirmation email to sent to this email and if they click the link, the account gets "verified". If they don't verify, the account gets deleted after a while.
I was told about another way: get the user to verify the email first, and when they click the verification link in their email they can start to create a username and password.
Does anyone see any problems with the second way, whether a security concern or anything else? It's not common and I personally cannot find a totally obvious problem with it, but I'd prefer to use it only after many people confirm they don't see problems or loopholes with it either.
Personally I do see an issue that can be inconveniencing for the user:
When most people register with a web site, they expect that they will have to answer quite a few questions, spend some time reading the FAQ and the terms of service and then spend some more time setting up some preliminary aspects of their profile.
The traditional flow allows the user to choose the time to go through that process. Afterwards, the user only receives a verification link, which normally is a 3-second process to use and can be done at practically any time.
Your proposed flow forces the potential user of your site to spend time reading your documentation, then wait until they receive the message and then find some more time, potentially after a few days, to fill in the forms. I, for one, would find that at least slightly annoying - if not outright discouraging - especially if the mail takes its sweet time to arrive, as it's often bound to do.
I also don't like the inherent implication of such a scheme:
Traditional flow: "Oh nice, you filled in our forms, just give us an address to send you a proper verification". The user here is merely waiting to complete what is essentially a done deal.
Mail-first flow: "Oh it's you. Well, wait for a while and we will send you an invitation if we want you". Here, on the other hand, the user is left in a limbo of subconscious uncertainty until they receive your message.
I believe that the first approach is far more open and friendly to the user. It's also the current standard flow for these cases, which should be enough of an incentive to use on its own - you should avoid forcing your users into processes they are not used to, unless there is no other way.
Getting an email from a friend with an invite link to access a site is exciting - it feels exclusive and new and fun. I'm being given something - so I gladly sign up.
Being required to enter an email address in order to start using a site feels draconian and restrictive and annoying. I'm being asked to give something up as the first step then possibly (maybe?) get something of value down the road.
It's not logical - in both cases, my email address is must be verified before an account can be created. In fact, the first case requires my friend to actively SPAM me with an offer I never requested.
Do you know why I first created this StackOverflow account? Because when I wanted to contribute an answer I could click on the Google logo on the login page and start using the site immediately. No username, password, first name, last name, DOB, or other B.S.
Do you know why I never created an Experts Exchange account? Because the first time I tried to access an answer I was prompted to enter a credit card number, billing address and phone number. Before I could even sample what the site had to offer, I had to give something up.
The point is this: barriers to entry make your site suck. Account creation should be as seamless and painless as possible. Being able to access a site immediately after filling out a single-page signup form and a CAPTCHA is awesome, even if access to other features is restricted until email verification is completed. Maybe I'll even tell you my DOB and favorite color if it unlocks more features.
Personally I don't see a problem with it - its a matter of choice. I think the key point though is making it clear to the user that they must
1) enter their email address
2) wait for a confirmation email before they can get to step 3
3) sign up for the account.
It potentially removes the amount of data held and time invested by the user if they only have to enter a single piece of information (their email address) before filling in the rest of the information you require.
Personally, I'd keep it standard so users don't get confused. The amount of work is the same - get a username/password/email address - wait for users to click the link before they can login to your site.
So how many times would you allow to use link send in email?
If only once, user can't create an account if he close browser before selecting username.
If multiple times, a lot of people can create accounts using same link. Publishing this link and using password recovery feature can be nice phishing trick.
And if you check for this email in your database and allow it only once, user would not be able to create two legitimate accounts.
I could see this method being slightly simpler - when the user clicks the verify link in their email, you send them to a form with a hidden pre-generated id number inserted, and then assign a username and password to it afterwards. Blank accounts, with just and id and no other information, are easy to periodically filter out and you're not storing any details whatsoever until the account is successfully created.
However, there's probably a reason why most sites collect username and password before email - you're getting a user invested before you ask for a more personal bit of information. The account is created - now just verify your email. The other way around ask for an email address first and an account second - even though functionally it's the same, perceptually it's not. Also, the advantage of the standard "flow" is that users know what to expect - following conventions mean users feel like they know what's happening and don't get confused or lose interest.
I want to share some thoughts about second approach.
First of all, it is very similar to invite system, but IT IS NOT the same.
You have to allow to send more than one registration request for a single e-mail address. If you don't - potential user might get it accidentally deleted and there will be no way to repeat the procedure. If you do allow that some angry dudes might use this as spam tool (send as many mails as possible to one(maybe even more) e-mail address. Imagine how would you company/site look for a person who got 10k registration requests...
Standard way has one serious advantage: it allows user name reservation without confirming e-mail (user might want to register, but don't want or has no access to the e-mail server/account).
You MUST consider that your server might delay email sending for pretty long time. Possible reasons: out of memory, DoS attack, email server failure and etc. If you choose mail first approach and user don't receive that mail in 5 minutes (for ANY reason), 3 of 4 potential users will course you company/site and never complete registration.
There is a reason why it is called a standard way, as a lot of small details are considered.
Both approaches are OK - but if you're going defer creation of the account, then you're going to have to embed all the required details into the URL - expiry date, username, password and email address and then encrypt it all to prevent tampering - which makes it rather large.
Actually - you couldn't allow people to pick their own usernames - since you'd have no way of checking whether the username had already previously been requested and not verified. And if you're going to publish usernames, then you'd therefore be publishing email addresses.....not such a good idea?
Here would be my concerns with this approach.
Email delivery is not guaranteed and can be slow. If the user doesn't get the email right away, they may not complete the registration process. What if they mistype their email address or if the email gets marked as SPAM?
In my experience, it is always better to keep record of the users that try to register to a site.
The problem is that more then often the users do not get the confirmation e-mail.
When that happens they often forget the site and do not come back.
What I do is to retry sending the confirmation e-mail after a while, say one week. Often they receive the second e-mail and you end up recovering a registered user that otherwise would be lost.
As a matter of fact, I retry sending the confirmation e-mail once every week until the user confirms or it passed 30 days since the registration attempt.
Even if the user does not confirm after 30 days, I do not delete the account. Often the user comes back trying to register again. Then I just send him again the account confirmation once again and encourage the user to contact the site if he does not get it again.
All this is to maximize the chances of recovering a registered user that otherwise could be lost.
I would suggest the second option. Let the users verify themselves by clicking the link in their email. Then they can choose their preferred username and password. I hope the usernames are unique in the site.
It would be helpful in the situation where some users forget to verify the link in their emails for a long time and so their usernames are locked. Others cannot choose those usernames (until that record is deleted later). Also this can eradicate spammers from picking their own usernames and locking them for use by others.
Hence i would suggest to go with the second option. Let the user first verify his email and his existence before he picks a username and locks it for use by others.
There are actually some sites that do that.
You enter your mail
you get a
verification mail with an initial
password and verification link
once you click the link your account is
active you're directed to a form with
additional details (full name, etc.)
but you may skip them and fill them
any time in the future.
This minimal registration process will help you avoid the loss of potential customers who don't want to bother with filling to many forms and supplying data before they really need to.
What it comes down to is convenience for the user. If the only reason for them the check their email is to verify the account then it may seem like an inconvenience. Instead have the system generate a password for them, email it to them, and instruct them to check their email to get their password. You can allow them to change the password after they log in if they want. This method also help to make sure "strong" passwords are out there initially.
I was asked by a person to create a php code, which is a part of a larger ERP software development project, so that he can test my skills. The code regarding a simple user authentication once the user registers through a form , by putting name, date of birth ,email.(which I have already done through html).
The action property of the html form, is a php file which consists of php code to get the posted inputs in the form, generate a verification link, and send it to the user via his/her email which he/she has already given.
I have two basic questions or problems:
How can this verification link be created?
Once the user clicks on this type of a link how does PHP know that they did so?
I don't think that there is any concept of event-driven programming in PHP. In that case, how does PHP handle that click and give a "conformational success message"? Is a MySQL database required or is there another easier way?
When you create the user, you are also going to generate a random string for that user. This is their authorization code. You will store it with the user's data in your database.
Then you are going to make your authorize page (ex., authorize.php). It will take a $_GET parameter of 'code', or whatever else you want (ex., authorize.php?code=theHashYouCreated). This page's code will look something like this:
if(!empty($_GET['code']))
{
/*
* Get the data from the database by the provided code.
* If a result is returned, then remove the authorization
* code from the user's record. If no user is found, then
* return an error.
*/
}
else
{
//No code was provided, so we should error.
}
Now, when the user tries to login you also want to check to see if their authorization code is set in the database. If it is, then they have not validated their e-mail address yet. If it isn't, then they have validated it.
Here's a nice tutorial that should help you create a confirmation email:
http://www.learnphponline.com/scripts/email-activation-for-php-forms
It involves creating a randomly generated activation key, that will initially be stored in the database. The key should be emailed to the user in the form of a GET parameter in a link.
Once the link is clicked, the submitted GET parameter is checked with the value in the database.