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.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | contrib-5.securesite.password6.junyor.patch | 7.56 KB | junyor |
| #9 | contrib-5.securesite.password5.junyor.patch | 8.46 KB | junyor |
| #8 | contrib-5.securesite.password4.junyor.patch | 8.46 KB | junyor |
| #3 | contrib-5.securesite.password3.junyor.patch | 6.24 KB | junyor |
| #2 | contrib-5.securesite.password2.junyor.patch | 6.73 KB | junyor |
Comments
Comment #1
junyor commentedComment #2
junyor commentedHere's a newer patch that also fixes a couple errors in the mail sending routine.
Comment #3
junyor commentedUpdated patch to latest DRUPAL-5 code. Update is currently untested.
Comment #4
whereisian commentedJust 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
Comment #5
junyor commentedIndeed. 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.
Comment #6
whereisian commentedThanks 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.Comment #7
junyor commentedWhat did happen when you added user/reset/* and user/password to you exception list?
Comment #8
junyor commentedUpdated 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.
Comment #9
junyor commentedThe last patch had a typo causing a PHP error.
Comment #10
junyor commentedUpdate 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.
Comment #11
junyor commentedChecked 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.
Comment #12
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.