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