Forum: Ruby on Rails Advise on signing up users and activating their accounts

5a710f2cb64255a2df3338c3325eae0c?d=identicon&s=25 Bizt (Guest)
on 2014-01-24 09:13
(Received via mailing list)
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
81b61875e41eaa58887543635d556fca?d=identicon&s=25 Frederick Cheung (Guest)
on 2014-01-24 09:18
(Received via mailing list)
On Friday, January 24, 2014 2:34:45 AM UTC+1, Bizt wrote:
> 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
1703a0c3ed358b787f4b1bf3b2799472?d=identicon&s=25 Blaine LaFreniere (Guest)
on 2014-01-24 09:23
(Received via mailing list)
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*: brlafreniere@gmail.com
  * *Web*: brlafreniere.com <http://brlafreniere.com>
52f3528c40e9cf28ad0900886eecb128?d=identicon&s=25 Jordon Bedwell (Guest)
on 2014-01-24 11:02
(Received via mailing list)
On Thu, Jan 23, 2014 at 7:34 PM, Bizt <martyn.biz@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.
52f3528c40e9cf28ad0900886eecb128?d=identicon&s=25 Jordon Bedwell (Guest)
on 2014-01-24 11:04
(Received via mailing list)
On Fri, Jan 24, 2014 at 4:00 AM, Jordon Bedwell <envygeeks@gmail.com>
wrote:
>
> I agree with Fredrick that this is a very premature optimization,

I must apologize, I misspelled Frederick's name.
5a710f2cb64255a2df3338c3325eae0c?d=identicon&s=25 Bizt (Guest)
on 2014-01-28 03:20
(Received via mailing list)
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
;)
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.