Binarylogic Authlogic

Comments and changes to this ticket

• 

  Ben Johnson February 12th, 2009 @ 01:25 PM

  • State changed from “new” to “open”

  I agree with you, but the problem is that not everyone has dirty attributes. They might have an older version of AR that doesn't have it. I guess in that instance I could fall back to using the current password.

• 

  Ben Johnson February 13th, 2009 @ 04:13 PM

  Alright, so I took a stab at implementing this and it causes problems with new records. That being said, what is wrong with checking the password before your change it? I would imagine that would make the most sense anyways, instead of the other way aropund. What do you think?

• You flagged this item as spam.
  

  LacKac February 14th, 2009 @ 12:21 PM

  What problems are we talking about? I'd argue with checking first making the most sense. Changing the password is an update on the account object really, which needs an extra validation. I would put this into the model this way not needing anything extra in the controller.

  I guess the compatibility problem could be solved by saving the crypted_password and password_salt fields to an instance variable on first modification of these values and using these if they exist when validating the password. For new records none of these is necessary, since we surely don't have an old password to validate.

  I'll try to do this modifications later tonight and submit a patch if it works out.

• 

  Ben Johnson February 17th, 2009 @ 03:18 AM

  Sounds good, it should be an easy change, but I was having issues with my tests. I'll see if I can work on it more as well, but help would be appreciated. Thanks!

• You flagged this item as spam.
  

  LacKac March 16th, 2009 @ 06:08 AM

  I tried to follow up and make it compatible with Rails 2.0 and below (pre Dirty feature), when I noticed that you use the dirty featureset too in validations to check if the email of login field was changed.

  So I guess there's nothing wrong using it for old password validation as well.

• 

  Ben Johnson March 23rd, 2009 @ 03:19 AM

  Sorry for the delay. I'm kind of on the fence with this, but I am leaning towards your side. How about this, if you can update your fork, make the changes, and have the tests pass then I'll include. I also agree that the "dirty" feature can be assumed installed, since I am using it throughout Authlogic.

• 

  Ben Johnson April 3rd, 2009 @ 01:21 AM

  • State changed from “open” to “resolved”

  Please let me know if this is still an issue.

• You flagged this item as spam.
  

  Aaron April 20th, 2009 @ 07:22 PM

  I'd like to see this change implemented as well. I just ran into the same error in my application:

  def validate_on_update unless self.old_password.nil?

  self.errors.add(:old_password, "Wrong password") unless valid_password?(old_password)
  
  

  end end

  This checks against the new password when user.password and user.password_confirmation are sent instead of checking against the old one

• 

  Ben Johnson April 22nd, 2009 @ 06:18 PM

  I decided to add better support for this. See this commit: http://github.com/binarylogic/au...

• You flagged this item as spam.
  

  Michael768 January 28th, 2019 @ 01:01 AM

  There's a Hash::check() function which allows you to check whether the old password entered by user is correct or not.

  usage

  if (Hash::check("param1", "param2")) {
  //add logic here }

  param1 - user password that has been entered on the form
  param2 - old password hash stored in database
  it will return true if old password has been entered correctly and you can add your logic accordingly

  for new_password and new_confirm_password to be same, you can add your validation in form request like tutuapp

  'new_password' => 'required', 'new_confirm_password' => 'required|same:new_password'