I’m developing registration wizard and faced with issue of robust email validation algorithm at the moment.
-
After we get user specified information like
first name,password,emailwe should save this info to DB. Lets also say we have appopriate table for this strings. -
Next we generate some email verification token (just generated code that consists of bunch of characters and digits) and also save it to DB with some timestamp (for timeout capability).
So, here I am frustrated. One of my requirements for algorithm is opportunity to send token not only one time, but multiple times. I require this for reason what letter wouldn’t be delivered to email or some technical issues on my side in result of that letter won’t send.
So by this reason, lets return to first step and allow user fill registration form again. Now we have data that user just entered and previous data which stored in DB.
Should we replace information that existing in DB with new one?
Another one requirement is that email address is unique and will used as user’s login. So we need transform above table with new one, what should accept one email two or more times in table.
Another one issue that has been dogging me for days is how can I remove unnecessary tokens from DB? Do I need to cron some job on night what goes thru tokens table and remove that tokens that is unwanted?
First of all, put requests for registration into a separate table from the membership table.
Second, when a user has registered, you create a token for validating the email address. If the user clicks the link that validates that token within X hours, you remove the token and create the user in the membership table.
If the user requests a new token, you just generate it and send the email message. If you overwrite the token in the DB, then obviously the link in the first email message will not work anymore, and that is fine — the user can only validate the most recent token.
If the user did not click the link that validates a token within X hours, then automatically the registration request can get cleaned up and the user will have to re-register. You can indeed to this with a cron-type job.
I hope this helps.