Hello, I''m having a weird problem in my user model. For the
change_password method I have the following:
def change_password(oldpass, newpass, confirmation)
oldpass = self.class.myhash(oldpass)
reload
passhash = self.password
self.password = newpass
self.password_confirmation = confirmation
if valid? and oldpass == passhash
save!
else
# valid? method clears errors so we have to call this after it
errors.add_to_base ''Invalid current password'' unless
oldpass == passhash
false
end
end
I also have validates_confirmation_of :password at the bottom of my
model. At some point in time (can''t remember when), the valid? method
stopped complaining when a confirmation isn''t provided. I have logged
the values of self.password and self.password_confirmation at the
point that valid? is called and self.password_confirmation is not set.
However, valid? succeeds and the password is changed, even though no
confirmation was provided. Any ideas as to why this might be
happening?
Thanks,
Carl
Hi, I think I figured this out. It seems like a bug to me, but when user.password_confirmation is nil the validation silently succeeds. If it is a String that is different from user.password it seems to work. On 10/14/05, Carl Youngblood <carl.youngblood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Hello, I''m having a weird problem in my user model. For the > change_password method I have the following:
Should that "bug" be caught with validates_presence_of :password_confirmation? Carl Youngblood wrote:>Hi, I think I figured this out. It seems like a bug to me, but when >user.password_confirmation is nil the validation silently succeeds. >If it is a String that is different from user.password it seems to >work. > >On 10/14/05, Carl Youngblood <carl.youngblood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > >>Hello, I''m having a weird problem in my user model. For the >>change_password method I have the following: >> >> >_______________________________________________ >Rails mailing list >Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >http://lists.rubyonrails.org/mailman/listinfo/rails > > > >
Well, if :password does not equal :password_confirmation or if :password_confirmation is not present, it seems to me that validates_confirmation_of should fail. That makes sense according to the logic of what that validation code is supposed to do--make sure that a matching confirmation has been provided for a given attribute. It doesn''t seem like someone should have to add another validation to make sure the first one works. I might be wrong here but it seems like there is a lot more surprise in your expected behavior than mine. Anyone else have any thoughts on this? Thanks, Carl On 10/14/05, Clint Pidlubny <clint-DOvxo+vduAZWk0Htik3J/w@public.gmane.org> wrote:> Should that "bug" be caught with validates_presence_of > :password_confirmation? > > Carl Youngblood wrote: > > >Hi, I think I figured this out. It seems like a bug to me, but when > >user.password_confirmation is nil the validation silently succeeds. > >If it is a String that is different from user.password it seems to > >work.
I think you''re right on this one. I was surprised by validates_associated not validating if it''s nil, but that turns out to be useful. This quirk seems unnecessary, really. On 10/15/05, Carl Youngblood <carl.youngblood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Well, if :password does not equal :password_confirmation or if > :password_confirmation is not present, it seems to me that > validates_confirmation_of should fail. That makes sense according to > the logic of what that validation code is supposed to do--make sure > that a matching confirmation has been provided for a given attribute. > It doesn''t seem like someone should have to add another validation to > make sure the first one works. > > I might be wrong here but it seems like there is a lot more surprise > in your expected behavior than mine. Anyone else have any thoughts on > this? > > Thanks, > Carl > > On 10/14/05, Clint Pidlubny <clint-DOvxo+vduAZWk0Htik3J/w@public.gmane.org> wrote: > > Should that "bug" be caught with validates_presence_of > > :password_confirmation? > > > > Carl Youngblood wrote: > > > > >Hi, I think I figured this out. It seems like a bug to me, but when > > >user.password_confirmation is nil the validation silently succeeds. > > >If it is a String that is different from user.password it seems to > > >work. > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
I''m pretty sure that the validates_confirmation_of : password_confirmation letting through either a matching password or nil is the intended behavior. They wanted a way for people to be able to edit their user profiles without the need to confirm their password everytime they need to make a change. So they decided to let nil through when that behavior is needed. Otherwise the password_confirmation needs to match the password if it is not nil HTH- -Ezra On Oct 14, 2005, at 1:01 PM, Carl Youngblood wrote:> Well, if :password does not equal :password_confirmation or if > :password_confirmation is not present, it seems to me that > validates_confirmation_of should fail. That makes sense according to > the logic of what that validation code is supposed to do--make sure > that a matching confirmation has been provided for a given attribute. > It doesn''t seem like someone should have to add another validation to > make sure the first one works. > > I might be wrong here but it seems like there is a lot more surprise > in your expected behavior than mine. Anyone else have any thoughts on > this? > > Thanks, > Carl > > On 10/14/05, Clint Pidlubny <clint-DOvxo+vduAZWk0Htik3J/w@public.gmane.org> wrote: > >> Should that "bug" be caught with validates_presence_of >> :password_confirmation? >> >> Carl Youngblood wrote: >> >> >>> Hi, I think I figured this out. It seems like a bug to me, but when >>> user.password_confirmation is nil the validation silently succeeds. >>> If it is a String that is different from user.password it seems to >>> work. >>> > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > >-Ezra Zygmuntowicz Yakima Herald-Republic WebMaster http://yakimaherald.com 509-577-7732 ezra-gdxLOakOTQ9oetBuM9ipNAC/G2K4zDHf@public.gmane.org
Wouldn''t it be possible to detect that the original field hadn''t changed and ignore the confirmation in that case? The current way of doing things seems rather surprising IMO. On 10/14/05, Ezra Zygmuntowicz <ezra-gdxLOakOTQ9oetBuM9ipNAC/G2K4zDHf@public.gmane.org> wrote:> I''m pretty sure that the validates_confirmation_of : > password_confirmation letting through either a matching password or > nil is the intended behavior. They wanted a way for people to be able > to edit their user profiles without the need to confirm their > password everytime they need to make a change. So they decided to let > nil through when that behavior is needed. Otherwise the > password_confirmation needs to match the password if it is not nil
Julian ''Julik'' Tarkhanov
2005-Oct-15 19:38 UTC
Re: validates_confirmation_of not working
On 14-okt-2005, at 20:47, Carl Youngblood wrote:> Hello, I''m having a weird problem in my user model. For the > change_password method I have the following: > > > I also have validates_confirmation_of :password at the bottom of my > model. At some point in time (can''t remember when), the valid? method > stopped complaining when a confirmation isn''t provided. I have logged > the values of self.password and self.password_confirmation at the > point that valid? is called and self.password_confirmation is not set. > However, valid? succeeds and the password is changed, even though no > confirmation was provided. Any ideas as to why this might be > happening?Password confirmation needs a virtual attribute called @<name_of_column>_confirmation, which is set not in the attributes hash but within the base object. I hope this solution helps you solve this problem for your case. I use implicitly-ciphered MD5 passwords but I allow people to enter them in clear text. private def cipher_password! unless password.to_s =~ /^[\dabcdef]{32}$/ write_attribute("password", MD5.new(password).to_s) # this is needed for virtual validation @password_confirmation = MD5.new (@password_confirmation).to_s if @password_confirmation end -- Julian "Julik" Tarkhanov