Email Activation in rails

Question

I have been looking through examples of email activation on rails and most examples just have a column for activation token and confirmed in their user table. I am not sure but I don't think that this is a good idea as when a user is activated almost both those columns seems like a waste. The way I was thinking of doing activation was having a seperate model called Activation which would have_one :user a ONE-WAY association and I would set the role of the user in my site as "PENDING" or something similar. The activation table would hold an activation token(s) per user. Then a link would be generated with the activation token(s) and the user would be sent an email containing something like www.mysite.com/activate?token='some_really_long_hash'. Upon clicking the link the role of my user would be set to "MEMBER" or something similar. Does this seem like a good idea? I can't conceive any pitfalls of activation this way. Suggestions? Comments?

Answer 1

It sounds like you're at the intro stages of implementing a state machine design pattern on your user model, and no it isn't a bad approach to design. Its just more complicated than what most people need.

I think the State Machine Plugin might be the type of approach you're looking to perform. Obviously this might be more than you're looking for but the approach would be the same.

Also check out these posts:

• Why developers should be force-fed state machines
• why-developers-never-use-state-machines

Good Luck!

Answer 2

The most straight-forward approach is to generate a random token and save it into a column of the user or member record. It doesn't have to be "really long", 20 random characters will suffice as the probability of guessing that is so slim it will never happen.

Typically the token is used once and once only to validate the user, but if the user clicks on the email a subsequent time it's nice if it still redirects back to their profile.

Usually the user is switched to "validated" or something of the sort, a status flag stored in a separate column. This preserves their initial membership type which might be one of many values. This is why you often see validated_at fields or banned_until fields.