[Plugin: Password Protected] Ability to store unhashed password?

Hi, OK is a bit tricky to add in a hook with the WordPress settings API, however I have reworked it a little so that you can intercept the password as plaintext before it is saved.

You can use the ‘pre_update_option_{option}’ filter with a priority of less than 10 to intercept the password as plaintext before it is saved. eg
add_filter( 'pre_update_option_password_protected_password', 'my_function', 10, 2 );

It will pass the new value and the old value as 2 parameters and expects the new value to be returned. Within this you could use the plaintext password and save as a separate option or something.

Would that work for you?
You can download the updated files to test here.

Working like a champ. thanks!

With one caveat… I’m not getting expected behavior when I click ‘Enable’ but don’t enter a password.

In this situation, both the hashed password and raw password get saved as the 2b877….. long string.

Here’s some ultra basic code code:

function cets_password_protected_modifier_save_pw($newvalue, $oldvalue) {
	update_option('pp_raw_password', $newvalue);
	return $newvalue;
}
add_filter( 'pre_update_option_password_protected_password', 'cets_password_protected_modifier_save_pw', 9, 2 );

any ideas?

Note: I changed my filter’s priority to 9 so it would run before your hashing filter at priority 10, but it’s still giving me this odd behavior in the case of an empty password.

Try doing a check before updating the option to test the $newvalue != $oldvalue

Sorry, I’ve thought about what you’ve said for quite a while, and don’t understand the logic here at all.

You’re suggesting I do something like:
if ($newvalue != $oldvalue) { save_raw_password($newvalue); }
?

I don’t actually understand either:
a) why I care if the new value equals the previous value or not
b) how this relates to the oddity when the password fields are left blank

Maybe it’s that I haven’t had enough coffee… but you’d think 4 cups would do it! ?? Cheers

Try echoing the $newvalue

I have a feeling that this might pass through the old hashed value if the new password is blank.

If so, $newvalue would be equal to $oldvalue, so if these values are the same if means nothing will have changed.

I might be wrong but I have a vague memory of something like this in my early testing.

Finally found some time to come back to this.

One thing I didn’t realize, which I found odd, is that the $oldvalue is in fact the hashed value of the old password, while $newvalue is the UNhashed text that was just entered. This gives me access to the raw password and allows me to save it. Great.

You’re correct that when the passwords are not confirmed correctly, oldvalue == newvalue and my check of
if ($oldvalue != $newvalue) {save_raw_password($newvalue);}
works great there.

There was one condition that I was still struggling with, but I think it’s just a case of me not understanding the plugin’s expected functionality in regards to someone submitting a form with ‘Enabled’ checked, but blank passwords entered. It seems that your plugin is simply not updating the password – is that your intended result? (Just confirming. If so, I think my modifier is doing what I want.)

Thanks again!

I think at the moment it doesn’t save a blank password (because you obviously can’t login with a blank password) but maybe you should be allowed to – it just means no-one will be able to login.

Marking this main issue as resolved.

I have added an issue regarding saving a blank password for future consideration.
https://github.com/benhuson/password-protected/issues/16

Just to clarify, yes, a user can’t save a ‘blank’ password.

A password will only be saved if it contains at least one character.

This is partly so that the password will not be reset every time you change the settings on the Privacy (or Reading in WP 3.5) admin page, and partly because it makes no sense to have a blank password – you might as well not have one.