Password reset bug on ClassicPress Directory reopened

Support
1

Hello all,

Following on from this recent topic, it appears that the signup process is still broken. Registration form works as expected, but password reset links always produce:

Error: Your password reset link appears to be invalid. Please request a new link below.

For me, this is regardless of whether &wp_lang=en_US is present in the URL or not.

Steps to reproduce

  1. Visit: Lost Password ‹ Directory — ClassicPress
  2. Request a new password.
  3. Click on the link to reset password.
  4. Receive “password reset link appears to be invalid” error.
  5. Fail to complete registration :frowning:

Context

I’m trying to sign up as a plugin dev in order to register CommentPress Core here. it’s a plugin that enables readers to comment paragraph-by-paragraph, line-by-line, block-by-block or by selecting text. It has never been updated to work with Gutenberg and requires the Classic Editor plugin - so would be a great fit here.

2

Again this depends on browsers.
Copy the reset link (instead of clicking it in the mail) and paste it in a new tab in the same browser window.

3

Thanks for responding. I’ve tried it every which way I can. Three different browsers, private windows, with and without query vars. No luck at all.

4

I need to tag @timkaye and @MattyRob on this. It seems that browsers do it again, stripping away things from password reset links…
(basically I was under the impression it was solved, but browser do receive updates and reintroduce the bug…)
for context what browsers have you tried? (know issue being already reported for Chrome and derivatives and for FireFox and derivatives)

5

Thanks again @ElisabettaCarrara FYI The lost password process works just fine with a fresh clone of the ClassicPress-release repo on my *nix localhost with PHP 8.2.x. I’m not seeing anything in my logs.

The only difference in code that I can see is that ClassicPress passes an options array when saving the cookie, while WordPress bleeding edge still passes separate params, i.e. uses the pre-PHP 7.3.0 function signature. Could it matter on your server? No idea :man_shrugging:

So I’ve tried the “Lost Password ‹ Directory — ClassicPress” process again, this time checking the cookies that are present before and after visiting in the reset URL (with and without the wp_lang query var). What I notice is that the wp-resetpass-longhashhere cookie is present on my localhost, but missing on directory.classicpress.net. (There is a cf_clearance cookie for the wider .classicpress.net domain). The missing cookie would account for the behaviour that I (and others) are seeing.

6

On MacOS, I’ve tried Safari, Brave, Firefox & Opera. I think the problem isn’t the browser but the missing cookie.

7

Have you tried using your phone instead?

8

@timkaye Thanks for the suggestion. I just tried - same result with Brave & Safari on iOS. Harder to inspect presence or absence of cookies though.

9

Ok, thanks for trying. I will see if I can take a look later today or tomorrow.

10

Thanks Tim. As I said previously, it seems that the “wp-resetpass-xxx” cookie isn’t being set. Could be a good place to start looking.

11

That’s exactly where I plan to start. Thanks!

12

I’ve now taken a look. The line $rp_cookie = 'wp-resetpass-' . COOKIEHASH; is in place, and the link being sent out looks just like the link that WP’s password reset link uses, except that the GET variables are in a different order.

So my surmise is that one or more of the following are true:

  1. The order of the variables is significant;
  2. The fact that CP is using an array is having an unintended consequence; or
  3. Something is happening in the email client.

It might indeed be that either 1 or 2 causes 3.

I’m going to DM you a new password. Then you can go in and change it to one you prefer.

13

I have now solved this. It turned out to be caused by an mu-plugin that we no longer need since we upgraded the algorithm used to create passwords in core.

2 Likes
14

So we can confirm that this problem is related to browsers and e-mail client?

So I think we need a page in docs to list different ways to restore lost passwords:

  • using SQL
  • using WP-CLI
  • using FTP or file editors to insert a code snippet

Then link that page in the lost password page.

1 Like
15

It seems so, @Simone. Could you write such a page? I can put it up and we can then do a PR to link to it from the code.

16

Sure.
I have already some ideas, just need to test some code before suggesting it.

1 Like
17

FWIW I don’t check email via a web UI and got the error when I copied and pasted the plaintext URL that I received - so (in my case) it seems unlikely that the error was related to browser(s) or e-mail client.

So I think we need a page in docs to list different ways to restore lost passwords

That’s not to say this isn’t a good idea - it is :slight_smile:

Tim wrote:

It turned out to be caused by an mu-plugin

Tim, does this mean there was a mismatch between the means of encoding the hash that was sent in the email and the means of verifying the hash on receipt of the rp request?

18

Also, I can confirm that the Lost Password process works as expected here now. Thanks for fixing.

2 Likes
19

Yes, that’s what was happening. That mu-plugin was providing the same level of security that’s now built into core but in a slightly different way, causing the mismatch. Now we have that functionality in core, we don’t need the plugin any more.

1 Like