I am writing up a user registration application in PHP as part of my learning pr

Question

I am writing up a user registration application in PHP as part of my learning process. I have written up the general rules my code should follow. Please let me know what you guys think of it.

Have a form with the email address and password.

Generate 2 random tokens to be appended to the URL to validate the email and complete the registration. Send user en email with the URLs. Use the first token to continue the registration and the second token to cancel (In the case where the registration request was unsolicited).

At this point, in the database table, I maintain a table with 6 columns - email, password, register_token, cancel_register_token, counter, timer.

When user clicks on the link to continue with the registration process, prompt the user for the password. If the user had inadvertently entered an incorrect email address, then that someone else obviously doesn't know the password and cant continue with the registration.

If the user who already has an active email in the db, waiting to register, wants an activation email sent again (maybe someone else registered the email on his behalf, unsolicited and he doesn't have the password to continue), then create another 2 random tokens, erasing the first set from the table and keeping a counter, increasing the counter each time a new set of tokens are generated against an email. When the counter reaches a maximum, do not accept any more requests. Maybe a max of 5 such requests and no more.

Keep the register link alive for 1 day if there is no activity. Use the timer column for the same.

Explanation / Answer

You're well on your way to a successful implementation of a user registration process. However, there are still some unknowns that you haven't addressed, that can impact your desired outcome.

How are you tracking that the user's account has been activated? It seems that once the user clicks the link to activate, there's no record that it's been activated in your database, as you don't have an "active/ated" flag set.
You will be hashing the password in the database, correct? You didn't really say either way in your question, but it's something to pay close attention to. Leaving a plain-text password in the database is a big no-no.
I don't know if keeping a counter of the number of tokens created serves you much of a purpose. If the user generates more than 5 (per your example), are you going to tell them "Sorry, tough luck, you've requested activation too many times"? I am with you on generating a new set of tokens and blowing away the old ones each time they request one, but I don't think it serves much purpose to limit them (unless you're wanting to prevent them from being able to predict and determine your token generating algorithm - in which case you need to look at generating a better algorithm instead).
Your timer is probably a safe bet. You might want to change it to be a "token_generation_datetime" or something instead, rather than a "timer". That way you can use it more for what it is. I think of a timer as a value demonstrating the length of time since an activity has started, or the amount of time remaining. In your case, since the data in that column is static based on the date that the tokens were generated, I'd use a different column name instead of "timer".
I'm not a huge fan of having to reenter my password when clicking on a hashed activation link in my email account. The fact that I received the email in my email account is verification enough that my email is valid. I shouldn't have to reenter my password again just to validate my email address.
Other than those points, you're on the right track with a user registration process. As @gnat pointed out, however, you need to look more at the big picture, and provide exactly what you're trying to do. "Is business logic correct?" is hard to answer, without understanding the scope and end-goal of what it is that you're trying to accomplish.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.