I'm having problems with the Request New Password form.

When a user requests a new password from the form, he receives an email with replacement login information and a reset URL. the URL brings the user to a form to change his password; however, the form requires the user to enter his current password. Since the user does not know his current password, he cannot enter a new password.

Also, another bit of information that may or may not be related: When the Admin trys to cancel an account through the administration menu, a message “you are not authorized to access this page” is displayed and the account is not cancelled.

Thanks in advance for help.

Comments

paulrooney’s picture

If you are logged in, you must know your current password to set a new password.

If you are logged in, but forget your password, there is a "reset password" link

If you click on that and then click on the one time link in the email that is generated - you'll be returned to the page where you have to enter your old password to set a new one.

You need to make sure you log out, and then go to user/password and request the password reset.

Then, while you are still logged out, click on the link from the email you receive.

In this case, you can change your password without needing to know the old one.

Anonymous’s picture

For my users, this is an endless loop. With each reset request, they get a one-time login, but are always required to provide their old password in order to set a new one. Requesting password reset starts the process over again.

How can I change the behavior of Drupal in this case? How can I get it to just e-mail them a new password?

Thanks for any help.

jadvies’s picture

Resetting works ok with the default setting for D7.
It is when you have a redirect that the problem arises.
What I am trying to do, since I have the same problem, is to create a rule and a trigger to redirect the user to the form to insert the new password. I am not there yet, but as soon as I have the solution I will post it here.

JayD’s picture

Thanks, this seems to work

magnetha’s picture

I'm seeing the same behaviour described by JayD and MadEye4 -- my users get stuck in the same password reset loop.

I understand from jadvies' comment that it's when you have a redirect that the problem arises.

I was using Login Destination, so I disabled it, uninstalled it, and cleared all caches. No luck.

I'm also using LoginToboggan, and I've disabled the redirections there. Still no luck.

Am I missing something really obvious? I'm a Drupal newbie (evidently) -- my thanks in advance to anyone who can point me in the right direction.

JayD’s picture

I thought this problem was fixed, but it's not

In testing, I discovered that the only way to set users password is for the admin to set. If a user tries to change the password set by the admin, he is denied when asked to enter his current password. The reset email also requires the user to use his current password, but that does not work either. There are no redirects on this form.

magnetha’s picture

Hmmm, I'm not seeing that behaviour (which makes me wonder if we're dealing with different problems here...?)

I'm running a class website for my students. Currently I need to manually set the password for each of my students at the time that they register for their accounts (due to the fact that the initial "set password" function requires a password). I give them a default password, which they then use to change their password. No one has had any problems changing their default password so far. (I know they're changing it, I've watched them do it.)

Of course when the students forget their new password, the password reset function won't work for them (due to the issue already discussed above). And so the manual password reset cycle continues.

I'm pretty sure the issue I'm having with my website has to do with some wonky redirects. I have Checklist 7.x-1.0-alpha1 installed (to keep track of my students' assignments). At some point I set the site up to redirect to the user's checklist upon login. I've tried to disable all redirects (see my previous message above) but students are still being redirecting to the checklist upon login. I think this might be the root of the problem for me, but I'm not sure.

Disabling Checklist isn't an option right now as we're in the middle of the term and my students are relying on their checklist to track their progress. (Yes, I am stupidly doing everything in production... I know, I know...) :( :( :(

Fortunately I learned all about release management last weekend at DrupalCamp Toronto! :) So I do plan to switch to a proper workflow over the Christmas break. But in the meantime I am really struggling to figure out how to fix this issue. Any advice would be much, much appreciated.

akayani’s picture

I match this exactly. I think I just applied about every patch to the user files there is.

Like you I'm using a checklist.

no2e’s picture

arun_drupal’s picture

Hello all,
I implemented custom theme in my site. During creating new user/forgot password one time login link was sent to user mail. When i click that link it will loads one time login page with login button. But when i click that login button it will not be redirected to user edit form. It throws "Problem loading page error" in firefox and "Redirect Loop error" in chrome.

But in bartik theme it works fine.This issue arises only for my custom theme.

Please anyone guide me over the solution.

FreeXenon’s picture

I am having the same issue.

kfriars’s picture

I am having the same problem. Have either of you had any success?

opgobee’s picture

I had the same problem as the original isue of JayD and magnetha, due to a redirect at login.

So I needed to adapt the redirect rule, such that the redirect would not occur upon a one-time-login at a password reset.

The solution could be found in comment #37 of this issue: https://www.drupal.org/project/rules/issues/480584#comment-9626805.

Also look at comment #25 of that thread for an explanation of the used approach in the condition (and a slightly variant solution).

Thanks for pointing to the redirect as the cause of the problem.