4 ms·

I loved the article and all the use cases are valid. However I don't think the first two use cases save that much effort. 1. In Rails apps with the devise gem

by sytse 12y ago

I loved the article and all the use cases are valid. However I don't think the first two use cases save that much effort. 1. In Rails apps with the devise gem the password reset token is just a column, not a whole other table. 2. Email activation, having the additional non-activated records is not a big problem, 20% extra records in my users table is pretty acceptable.

bryanlarsen 12y ago
Since Rails 4.1, the technique described in the article is trivial to use. Check out message_verifier.
- sytse 12y ago
  I looked it up, http://api.rubyonrails.org/classes/ActiveSupport/MessageVerifier.html http://api.rubyonrails.org/classes/ActiveSupport/MessageVeri... looks cool, but didn't find a quick way to use it with Devise.
bryanlarsen 12y ago
It's not the extra database columns, it's the removal of a state field. The additional of a single boolean state field essentially doubles your API area because now you have two types of users that may try to do things, and it's highly unlikely you have saturation testing for unverified users.
- sytse 12y ago
  That makes sense, normally Devise handles that for me https://github.com/plataformatec/devise https://github.com/plataformatec/devise
- tomjen3 12y ago
  Actually rails has (or had I haven't looked at it seriously since the load and execute all the yaml fiasco) a relatively simple before filter (it may have been called before_filter, actually) that you use to filter out users who are not signed in, it wouldn't be difficult at all to change that to check the user was signed in and verified and to update the single place where the user is allowed in (likely /verify) as an unverified user to not use that filter. Django has native support for unverified users. That said it is still a good point.
  - bryanlarsen 12y ago
    But that's not the only place you use users. What about batch jobs? What about every place where you get a list of users for the admin for one reason or another? Did you cover and test those? Devs seriously underestimate how much the additional of a state field impacts their code, especially once you get the combinatorial explosion of several state variables interacting...

by sytse 12y ago

bryanlarsen 12y ago

Since Rails 4.1, the technique described in the article is trivial to use. Check out message_verifier.

sytse 12y ago
I looked it up, http://api.rubyonrails.org/classes/ActiveSupport/MessageVerifier.html http://api.rubyonrails.org/classes/ActiveSupport/MessageVeri... looks cool, but didn't find a quick way to use it with Devise.

bryanlarsen 12y ago

It's not the extra database columns, it's the removal of a state field. The additional of a single boolean state field essentially doubles your API area because now you have two types of users that may try to do things, and it's highly unlikely you have saturation testing for unverified users.

sytse 12y ago
That makes sense, normally Devise handles that for me https://github.com/plataformatec/devise https://github.com/plataformatec/devise
tomjen3 12y ago
Actually rails has (or had I haven't looked at it seriously since the load and execute all the yaml fiasco) a relatively simple before filter (it may have been called before_filter, actually) that you use to filter out users who are not signed in, it wouldn't be difficult at all to change that to check the user was signed in and verified and to update the single place where the user is allowed in (likely /verify) as an unverified user to not use that filter. Django has native support for unverified users. That said it is still a good point.
- bryanlarsen 12y ago
  But that's not the only place you use users. What about batch jobs? What about every place where you get a list of users for the admin for one reason or another? Did you cover and test those? Devs seriously underestimate how much the additional of a state field impacts their code, especially once you get the combinatorial explosion of several state variables interacting...