Re: [Rails] Advise on signing up users and activating their accounts
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 ;) -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Talk group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-talk@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/dd881344-66c7-489f-a896-cc252c51636e%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Rails] Advise on signing up users and activating their accounts
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*: brlafreni...@gmail.com * *Web*: brlafreniere.com http://brlafreniere.com -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Talk group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-talk@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/52E22284.3000205%40gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Rails] Advise on signing up users and activating their accounts
On Thu, Jan 23, 2014 at 7:34 PM, Bizt martyn@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. 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. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Talk group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-talk@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CAM5XQnyJ1u-b6S1q%2Bz07L3NpoejtgECDTuyFSpWs_%2BC7yF9U5A%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Rails] Advise on signing up users and activating their accounts
On Fri, Jan 24, 2014 at 4:00 AM, Jordon Bedwell envyge...@gmail.com wrote: On Thu, Jan 23, 2014 at 7:34 PM, Bizt martyn@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. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Talk group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-talk@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CAM5XQnxPE2f5zGqZFCV8K56%3D6GRwuiM8ZHjiLyjSuP5KCSZOvA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
