0

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.

  1. Have a form with the email address and password.

  2. 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).

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

  4. 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.

  5. 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.

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

Improve this question
6
  • Unclear what help you need. Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it’s hard to tell what problem you are trying to solve or what aspect of your approach needs to be corrected or explained. See the How to Ask page for help clarifying this question. Commented Apr 14, 2014 at 16:10
  • @gnat I am asking if the business rules make sense, or is there a flaw in it. Commented Apr 14, 2014 at 16:15
  • meta.programmers.stackexchange.com/a/6504/31260 Commented Apr 14, 2014 at 16:49
  • @user1720897 What are the requirements? We should check your business rules against what? A simple form that directly writes up everything into the database and set the user's session to authenticated, that is also correct, unless you say it doesn't fulfill the requirements. Commented Apr 14, 2014 at 17:11
  • @Mahdi Honestly, I am not sure about what my business rules should be checked against. Please keep in mind that this is not a production code. Its just somebody trying to learn something. My requirements are like so - Provide a 2 step user registration process. The first step validates the email that the registration request comes from. Then in step 2, after validating the email through the activation link, complete the user registration process. Commented Apr 14, 2014 at 17:41

1 Answer 1

Reset to default
2

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.

  1. 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.
  2. 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.
  3. 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).
  4. 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".
  5. 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.

Improve this answer
1
  • 1. I will have 2 tables in my database. One to maintain potential users. So when the user clicks on the activation link, the user will be moved to the permanent table. This is how I want to track them. 2. Yes, I will be hashing the passwords. 3. I am keeping a counter to check unsolicited user registration attempts. I do not want somebody to spam someone else's email account. 4. Noted. 5. Why I want to have this password protected is in the case, where the email was inadvertently sent to the incorrect email address, they would be no way to continue the registration. Commented Apr 14, 2014 at 17:31

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.