CUNY Academic Commons

So far I have been unable to reproduce the issue. Here's a walkthrough of what I'm doing. See also the attached gif.

1. Visited home page, logged out
2. Clicked Login button, leading me to https://commons.gc.cuny.edu/wp-login.php
3. Clicked "Lost your password?", which took me to https://commons.gc.cuny.edu/wp-login.php?action=lostpassword
4. Filled in my username and clicked 'Get New Password'
5. I received an email with a 'Reset Password' link that has the format https://commons.gc.cuny.edu/wp-login.php?action=rp&key=xxxxxxxxxxxxxxxxxxxx&login=boonetest, where the xxxxx section is a unique key
6. I was led back to a page with a URL of the format: https://commons.gc.cuny.edu/wp-login.php?action=rp. Note that the key and and login are stripped from the URL at this point, as WP has already verified them and redirected me
7. I selected a new password and saved changes, which led me to https://commons.gc.cuny.edu/wp-login.php?action=resetpass, a success screen

Piecing together what I'm hearing, something is failing around 5 and 6. The user is getting the email, but when clicking, the user isn't redirected to the reset screen, but instead gets a message about an invalid key. I'm attaching a screenshot of what that page looks like.

It could be that something is happening with multiple redirects, which might invalidate the key in the background. I'll try to reproduce and investigate further, but if anyone could verify that my interpretation is correct, it would be a helpful start. Or if anyone can reliably reproduce, that would also be helpful.

I figured out the bug. It's unrelated to Reclaim or caching. It's a bug I introduced in the changes related to the 2.5 release. See #21409. In that ticket I used the 'send_retrieve_password_email' hook in WP. The second param passed to that hook is called $user_login. So, when I built the password reset key for our custom email, I trusted that it was, you know, the user_login. But it turns out that this is actually the raw value provided by the user in the 'Username or email address' field. If a user passed their user_login, then the reset worked fine. But if they passed their email address, then the key hash logic failed. I've made a change so that I actually use the user_login value from the WP_User object: https://github.com/cuny-academic-commons/cac/commit/7ac1c8cce58756929758defe8adc97bd954ba2b4

You can confirm on the production server by going through the password reset flow using an email address.

Very good, thanks. I'm tentatively closing this. Marilyn, Laurie, and others - please reopen with details if you get more reports of the same, though I don't think you will.