Using the latest development version results in the user not being able to use the one-time login link they receive by email when using the reset password function.

What happens:

  1. User requests a password reset
  2. User clicks link in email
  3. User gets "Reset Password" form
  4. User clicks the "Log In" button on the page
  5. User gets a "Unable to find server" error message

On step 4, the "action" parameter of the "form" tag has a double-slash in front, which confuses the browser about what server it should send the form to.

Looking at the code for "chgpwd_form_user_pass_reset_alter", seems like there's already a slash at the beginning of the "#action" and calling "url" on it adds a second one.

I fixed it on my site by changing line 108 of chgpwd.module to:

$form['#action'] = url(substr($form['#action'], 1), array(

I haven't researched if this fix causes nasty side-effects so caveat emptor.

Comments

vinoth.3v’s picture

vinoth.3v commented
Assigned: Unassigned » vinoth.3v
Status: Active » Fixed

Thank you for reporting this.

It is fixed and committed to git just now.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

samalander’s picture

samalander commented
Status: Closed (fixed) » Needs work

Hi,

Thanks for the fix but this introduces another bug in the process. In the new "chgpwd_form_user_pass_reset_alter" function of "chgpwd.module", line 106 reads:

$uid = module_exists('me')? 'me':$form['#parameters'][2];

The "$uid" variable is then used to create the form URL ("user/reset/$uid/$timestamp/$hashed_pass/login"). But if the user isn't logged in yet, which they would never be since they are using the password reset link, then the "me" that gets put in there as the user ID if the "Me" module is active is meaningless and the form fails to log the user in (actually, it requests a login to access it...).

I've replaced the above line in mine with:

$uid = $form['#parameters'][2];

And it now works as expected.

Thanks.