Password reset form requires username and e-mail address, but only asks for one or the other
Junyor - August 23, 2007 - 04:21
| Project: | Secure Site |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
The password reset form says that you can enter your username or password, but it does not work unless you enter both. This happens because securesite_user_auth() does a check for if ($_POST['securesite_request_form'] && $edit['name'] && $edit['mail']), i.e. if the request from has been posted and both name and mail are filled in. Only then does it actually query the database to see if the user is valid and send an e-mail with the password.
I've cleaned up the code in securesite_user_auth a bit to fix this problem and make it a bit more clear what happens.
#1
#2
Here's a newer patch that also fixes a couple errors in the mail sending routine.
#3
Updated patch to latest DRUPAL-5 code. Update is currently untested.
#4
Just installed securesite 5.x-1.x-dev, Last updated: January 17, 2008 - 12:12 and this issue is still occurring. Works with both username AND password, but not username OR password.
Cheers
#5
Indeed. No fix has been committed since the old password reset method from the DRUPAL-4-7 branch was removed. See http://drupal.org/node/30492 for details. http://drupal.org/node/204191 describes the problem in DRUPAL-5, i.e. password resetting doesn't work since the URL is blocked. I haven't figured out a good solution for that yet.
#6
Thanks for poking around. I've attempted adding
user/reset/*anduser/passwordto my exceptions list, but that didn't help. I'll keep an eye out.#7
What did happen when you added user/reset/* and user/password to you exception list?
#8
Updated patch for DRUPAL-5 branch. I realized this patch has nothing to do with the password reset stuff, since it's unchanged before and after the patch.
This patch needs fairly thorough cross-browser testing since it changes some of the circumstances under which the login/password reset form are shown instead of HTTP Auth. In order to make errors more apparent, the patch will not show HTTP Auth if the login or password reset forms had just been submitted.
#9
The last patch had a typo causing a PHP error.
#10
Update to DRUPAL-5 and removed an unneeded check. The $account variable won't be set at that point unless the user has reset their password. In either case, we want the user to enter their credentials, so I just removed the check.
#11
Checked in modified patch to DRUPAL-5 after additional testing. Verified that the changes work in Opera 9.2x, IE 7, and Firefox 2. Safari 3 is broken for other reasons.
This check-in also fixed the password sent out in password reset mails from Secure Site.
#12
Automatically closed -- issue fixed for two weeks with no activity.