has_secure_password should accept an optional option #1512

Closed
gucki opened this Issue Jun 6, 2011 · 14 comments

Comments

Projects
None yet
@gucki

gucki commented Jun 6, 2011

It should be possible to pass :optional => true to has_secure_password, which would simply skip adding the validations.

Would a patch for this be accepted? :)

@josevalim

This comment has been minimized.

Show comment
Hide comment
@josevalim

josevalim Jun 7, 2011

Contributor

I am -1 for adding more features to has_secure_password. If you want more customization, there are plenty auth tools out there.

Contributor

josevalim commented Jun 7, 2011

I am -1 for adding more features to has_secure_password. If you want more customization, there are plenty auth tools out there.

@josevalim josevalim closed this Jun 7, 2011

@joelmichael

This comment has been minimized.

Show comment
Hide comment
@joelmichael

joelmichael Sep 15, 2011

Contributor

I am also in favor of making this optional, as I have a model that has optional login functionality. Actually, I'm not sure the "validates_presence_of :password_digest" serves any real purpose, and it's the only thing causing me trouble. Removing that line seems like it would suffice.

Contributor

joelmichael commented Sep 15, 2011

I am also in favor of making this optional, as I have a model that has optional login functionality. Actually, I'm not sure the "validates_presence_of :password_digest" serves any real purpose, and it's the only thing causing me trouble. Removing that line seems like it would suffice.

@bloomdido

This comment has been minimized.

Show comment
Hide comment
@bloomdido

bloomdido Sep 29, 2011

I know this issue has been closed, but I am +1 for making the ability to turn off validation an option. I have two different applications right now with simple user classes that use has_secure_password, and both have a need to allow the password to be blank for completely different reasons. However, without some hackery (i.e. accessing the model's validations hash and brute force removing the :validates_presence_of proc) or completely overriding has_secure_password, there is no way to prevent the validation from occurring. A simple option that is passed into has_secure_password would solve that without in anyway making it more complicated to use. The default is still to validate presence (and confirmation).

I know this issue has been closed, but I am +1 for making the ability to turn off validation an option. I have two different applications right now with simple user classes that use has_secure_password, and both have a need to allow the password to be blank for completely different reasons. However, without some hackery (i.e. accessing the model's validations hash and brute force removing the :validates_presence_of proc) or completely overriding has_secure_password, there is no way to prevent the validation from occurring. A simple option that is passed into has_secure_password would solve that without in anyway making it more complicated to use. The default is still to validate presence (and confirmation).

@seivan

This comment has been minimized.

Show comment
Hide comment
@seivan

seivan Nov 1, 2011

+1 I don't want password confirmation.
It's not much of a feature, :validate => false. Done

seivan commented Nov 1, 2011

+1 I don't want password confirmation.
It's not much of a feature, :validate => false. Done

@gucki

This comment has been minimized.

Show comment
Hide comment
@gucki

gucki Nov 1, 2011

+1 again

gucki commented Nov 1, 2011

+1 again

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Dec 26, 2011

+1 here, for the removal of the validation altogether.

I have lost count of times where I needed to implement secure password myself, recreating the has_secure_password functionality just because I wanted to get rid of this implicit validation.

Perhaps there's some need for it that I don't realise, but shouldn't it be the responsibility of the class itself to declare "validates :password, presence: true" or { on: :create } or whatever the specific implementation case is? Why the implicit validation at all? So counter-intuitive...

ghost commented Dec 26, 2011

+1 here, for the removal of the validation altogether.

I have lost count of times where I needed to implement secure password myself, recreating the has_secure_password functionality just because I wanted to get rid of this implicit validation.

Perhaps there's some need for it that I don't realise, but shouldn't it be the responsibility of the class itself to declare "validates :password, presence: true" or { on: :create } or whatever the specific implementation case is? Why the implicit validation at all? So counter-intuitive...

@zoran

This comment has been minimized.

Show comment
Hide comment
@zoran

zoran Feb 8, 2012

+1 for skip validation - same problem as bloomdido

zoran commented Feb 8, 2012

+1 for skip validation - same problem as bloomdido

@ay

This comment has been minimized.

Show comment
Hide comment
@ay

ay Apr 24, 2012

Contributor

+1 for having an option to skip validates_presence_of :password_digest

Contributor

ay commented Apr 24, 2012

+1 for having an option to skip validates_presence_of :password_digest

@seraphinmiranda

This comment has been minimized.

Show comment
Hide comment
@whalesalad

This comment has been minimized.

Show comment
Hide comment
@whalesalad

whalesalad Sep 6, 2012

Massive +1 from me. @josevalim I see your point, but one thing I really love about has_secure_password is just how simple it is to integrate. I don't want to have to install something as complex and monolithic as devise or authlogic in my current lightweight/simple rest api site. However, I would love to allow facebook users to have an empty password!

That being said ... my current solution is to simply calculate a hashed password for them now based on certain user parameters.

Massive +1 from me. @josevalim I see your point, but one thing I really love about has_secure_password is just how simple it is to integrate. I don't want to have to install something as complex and monolithic as devise or authlogic in my current lightweight/simple rest api site. However, I would love to allow facebook users to have an empty password!

That being said ... my current solution is to simply calculate a hashed password for them now based on certain user parameters.

@zhangandyx

This comment has been minimized.

Show comment
Hide comment
@zhangandyx

zhangandyx Sep 8, 2012

@whalesalad When/how are you setting this password? I can only set it in the User.new stage, which doesn't work for me.

@whalesalad When/how are you setting this password? I can only set it in the User.new stage, which doesn't work for me.

@whalesalad

This comment has been minimized.

Show comment
Hide comment
@whalesalad

whalesalad Sep 8, 2012

Right now in my UserController#create method i'm automatically setting password_confirmation to the value of password. Also, in my User model, I have before_validation :bootstrap_facebook_account, :on => :create which calls my custom method when the user is created, but before it is validated/saved. In that method I bootstrap the user with as much data from facebook that I can and also set their password to a salted hash of their user created_at and facebook_id so that I can re-create it later on. Since all this occurs before validation, by the time that stuff happens the User object is ready to rock.

Keep in mind I am building a very simple private API for an iPhone client, so while security is a priority, certain things can be avoided due to the fact that my only real user is the app itself, which I am also developing.

Right now in my UserController#create method i'm automatically setting password_confirmation to the value of password. Also, in my User model, I have before_validation :bootstrap_facebook_account, :on => :create which calls my custom method when the user is created, but before it is validated/saved. In that method I bootstrap the user with as much data from facebook that I can and also set their password to a salted hash of their user created_at and facebook_id so that I can re-create it later on. Since all this occurs before validation, by the time that stuff happens the User object is ready to rock.

Keep in mind I am building a very simple private API for an iPhone client, so while security is a priority, certain things can be avoided due to the fact that my only real user is the app itself, which I am also developing.

@rafaelfranca

This comment has been minimized.

Show comment
Hide comment
@rafaelfranca

rafaelfranca Sep 8, 2012

Member

Please guys, look to the code https://github.com/rails/rails/blob/master/activemodel/lib/active_model/secure_password.rb#L44-48 and you will see that this feature was added 4 month ago.

Member

rafaelfranca commented Sep 8, 2012

Please guys, look to the code https://github.com/rails/rails/blob/master/activemodel/lib/active_model/secure_password.rb#L44-48 and you will see that this feature was added 4 month ago.

@zhangandyx

This comment has been minimized.

Show comment
Hide comment
@zhangandyx

zhangandyx Sep 8, 2012

Thanks guys...I see it in master...looking forward to it in the next release!

Thanks guys...I see it in master...looking forward to it in the next release!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment