Remove Ardent's auto-hashing of the password about confide

I found a quick work around for the moment:

The password property can be unset so that it is empty and not saved during the update. unset($user->password); // Required so Ardent doesn't rehash the already-hashed password. This will prevent saving a double hashed password. Just use this before using $user->save(); when updating the user's info, unless you're intentionally trying to change the password field with new input.

So I don't know if this is something you guys still want to changed in Confide. I think it's probably still a good idea. The worry being that a developer could potentially destroy their user's password hashes if they get double hashed with this 'gotcha' when trying to update the user's info. But the above is a short term fix for anyone encountering this.

[andrew13]

Yeah thats how I've been doing it. If the confirmation password isn't set
it unsets both. I assume that if both are passed in, then its meant to be
set. Otherwise it's ignored.

On Mon, Apr 8, 2013 at 5:11 PM, Jason [email protected] wrote:

I found a quick work around for the moment:

The password property can be unset so that it is empty and not saved
during the update. unset($user->password); // Required so Ardent doesn't
rehash the already-hashed password. This will prevent saving a double
hashed password. Just use this before using $user->save(); when updating
the user's info, unless you're intentionally trying to change the password
field with new input.

So I don't know if this is something you guys still want to changed in
Confide. I think it's probably still a good idea. The worry being that a
developer could potentially destroy their user's password hashes if they
get double hashed with this 'gotcha' when trying to update the user's info.
But the above is a short term fix for anyone encountering this.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/59#issuecomment-16087015
.

If the confirmation password isn't set
it unsets both. I assume that if both are passed in, then its meant to be
set. Otherwise it's ignored.

I don't think that's correct. For example, in my case the password confirmation is not set (given the data comes from the users table which doesn't have a column for the password confirmation). Yet the password property is not ignored and it does rehash the existing password hash, causing future login attempts for that user to fail.

To clarify, I don't recommend the unset method as a permanent solution (just as a temp fix for yesterday) because it leaves the unexpected behavior within Confide to trip up future Confide users. Whereas just using Hash::make() where needed within ConfideUser.php would solve this problem.

[andrew13]

Not in Confide. In my model for my application it unsets both the password and password_confirmation fields if they are not set. (It also fails validation if they don't match.) It doesn't rehash the password.

An alternative is to check if the hash is unmodified and if so, remove it from the update array. Of course that is tricky, because what if they entered the exact hash (unlikely I know) then password would not be reset when it should be.

[andrew13]

I'll need to figure out what the best way to remove and then add the hashing elsewhere.

[Zizaco]

@andrew13 Any news on this? Does the purpose of the "amend" is to fix this?

[andrew13]

Amend does resolve this issue as far as I am concerned. Closing.

@andrew13 What do you mean by 'Amend'? Can you link to it or to the commit that fixes this please? So I can see what you guys are referring to and can figure out how to change my own code as well. Thx.

[andrew13]

See https://github.com/Zizaco/confide#update-an-user

Thanks

[andrew13]

No problem