Advise on signing up users and activating their accounts

[Bizt]

I'm new to Rails but so far I've completed the Rails Tutorial book and applying that stuff to my first proper app. Later I will tackle implementing user authentication (sign up, sign in, sign out)

In the book it demonstrates very well how to sign users up, validate, etc. Usually in my PHP apps I have a process of allowing the user to signup, then they are sent a link to confirm their email address, then (from that link in the email) they can activate their account. In the backend, I use two tables - user_pending (for users who have signed up, but not yet activated their account), and user (for activated users). I decided a while back that I would use two tables as I didn't want the user table to get bogged down with users who never activate their account. Perhaps this is not too important, and I'm giving myself more work.

Anyway could someone perhaps comment on what is the most commonly practiced technique for activating users - I'm assuming via email activation as this is what I see most when I sign up for new apps myself. If I do this process, should I use one table (user - with "activated" flag column) or two tables (user_pending and user - when users activate, the row is copied to user). Any comments welcome, especially if their is a newer better way to perform this process.

Thank you

[Frederick Cheung]

On Friday, January 24, 2014 2:34:45 AM UTC+1, Bizt wrote:

I'm new to Rails but so far I've completed the Rails Tutorial book and applying that stuff to my first proper app. Later I will tackle implementing user authentication (sign up, sign in, sign out)

In the book it demonstrates very well how to sign users up, validate, etc. Usually in my PHP apps I have a process of allowing the user to signup, then they are sent a link to confirm their email address, then (from that link in the email) they can activate their account. In the backend, I use two tables - user_pending (for users who have signed up, but not yet activated their account), and user (for activated users). I decided a while back that I would use two tables as I didn't want the user table to get bogged down with users who never activate their account. Perhaps this is not too important, and I'm giving myself more work.

This does rather sound like premature optimisation to me. 

 

Anyway could someone perhaps comment on what is the most commonly practiced technique for activating users - I'm assuming via email activation as this is what I see most when I sign up for new apps myself. If I do this process, should I use one table (user - with "activated" flag column) or two tables (user_pending and user - when users activate, the row is copied to user). Any comments welcome, especially if their is a newer better way to perform this process.

 

The standard approach is email activation with a single users table. A lot of people use the devise gem for authentication, which has this built in -  - you could either just use devise or examine its approach in more detail before rolling your own.

Fred

 

Thank you

[Blaine LaFreniere]

On 1/23/14, 6:34 PM, Bizt wrote:

Anyway could someone perhaps comment on what is the most commonly practiced technique for activating users

I would suggest the Devise gem, which is pretty commonly used. It's very thorough and complete. It comes with the ability to recover passwords via e-mail, and lots of other nice features.

--

• Blaine LaFreniere
• Phone: 801-448-6124
• E-mail: brlafr...@gmail.com
• Web: brlafreniere.com

[Jordon Bedwell]

On Thu, Jan 23, 2014 at 7:34 PM, Bizt <marty...@gmail.com> wrote:
> In the book it demonstrates very well how to sign users up, validate, etc.
> Usually in my PHP apps I have a process of allowing the user to signup, then
> they are sent a link to confirm their email address, then (from that link in
> the email) they can activate their account. In the backend, I use two tables
> - user_pending (for users who have signed up, but not yet activated their
> account), and user (for activated users). I decided a while back that I
> would use two tables as I didn't want the user table to get bogged down with
> users who never activate their account. Perhaps this is not too important,
> and I'm giving myself more work.

I agree with Fredrick that this is a very premature optimization,
considering it will not hurt your tables at all and by the time it
does you will know enough to partition or shard or both and even if it
wasn't two tables is an excessive waste. To me the idea should never
to remove a user if they are not "validated" but simply to limit their
actions and annoy them (not by email, with a big ass annoying yellow
box on the site,) which can all be done on a single table.

We don't remove users (valid or not) unless they explicitly request
(because it's only fair that if I collect data on them they have the
right to remove it -- irregardless of what the law says it's a moral
decision we make.)

The moral of the story is that if you have one or two tables you are
still going to have to hit the db to clean up if you need to clean up,
why make it a separate table at that point when you can just adjust
the where clause to check another column that is a boolean field?
That's useless decoupling.

[Jordon Bedwell]

On Fri, Jan 24, 2014 at 4:00 AM, Jordon Bedwell <envy...@gmail.com> wrote:
> On Thu, Jan 23, 2014 at 7:34 PM, Bizt <marty...@gmail.com> wrote:
>> In the book it demonstrates very well how to sign users up, validate, etc.
>> Usually in my PHP apps I have a process of allowing the user to signup, then
>> they are sent a link to confirm their email address, then (from that link in
>> the email) they can activate their account. In the backend, I use two tables
>> - user_pending (for users who have signed up, but not yet activated their
>> account), and user (for activated users). I decided a while back that I
>> would use two tables as I didn't want the user table to get bogged down with
>> users who never activate their account. Perhaps this is not too important,
>> and I'm giving myself more work.
>
> I agree with Fredrick that this is a very premature optimization,

I must apologize, I misspelled Frederick's name.

[Bizt]

Hi guys, thanks for the many responses. I guess I've been doing it slightly wrong then, glad to have a better idea of how it is most commonly implemented.

And yes, I've discovered Devise and used that within my site. Great addition, much better than doing it all myself (as I said, I'm new to Rails ;)