Password request form ineffective due to site protection

See http://drupal.org/node/30492. We previously fixed this by not using the one time password URLs, but that fix was lost.

Are there any security-implications to adding user/reset/* to the exception list?

If there are problems with the password, the user is redirected to /user/password to request a new password again. We'll have to find some work-around for that.

It looks like it won't work even if you do add the user/reset/* page. The hash sent out in the mail from Secure Site is wrong, as it uses the old password instead of the new password.

I just checked in a fix to the DRUPAL-5 branch that fixes the password hash problem I mentioned in #5. Password reset URLs work now if you add "user/reset/*" to the bypass list. I realized adding "user/password" is not necessary, since the messages generated by the user module when the user is redirected to user/password to reset their password are still relevant for the form Secure Site uses.

An automated fix would be to add a check like the following to the bypass checks at the top of securesite_init (completely untested):

  || (strpos(request_uri(), $base_path .'user/reset/') === 0) // Accessing password reset page

I'll look into making a patch for that some time soon.

OK, my suggestion would mostly work, but it could get ugly if you just went to /user/reset/ with invalid parameters. So, I've added in some code that validates and passes all the parameters to user_pass_reset() instead of relying on the menu system. This patch needs to be thought through carefully to make sure there aren't any attack vectors.

I'd appreciate feedback on the patch from the others maintaining this module and using this module before it gets committed.

+1 to your patch. Looks fine to me. The email sends fine and the one time link works mostly. The link runs and I get a message on the dialog page telling me I am logged in and should now please change my password, but I was not logged in. But I was redirect to the user edit path (user/#/edit)

I have not been able to work out the problem.

Off topic;
The attached patch takes some of your last few cleanup commits a small step further.
It firstly fixes the dialog CSS to work in older IE versions and I would just like to say I really like the new default look of the dialog, its theme independent.
Secondly I moved the output from the user_auth function to its own function and then used it in user_auth.
Once this was done I made the password reset message use drupal messages and the dialog.

That's weird that you had trouble logging in. It always logged me in without trouble.

I'll take a look at your clean-up patch later. Would you mind creating a separate issue for it?

@NaX: Are you using DRUPAL-5 for core instead of the official 5.7 release? If so, you might be seeing http://drupal.org/node/165642#comment-738095.

Ok I tried to recreate the problems I was having and try to find the problem, but I can’t reproduce the issue any more. I don’t know why but everything works fine now. I recon this patch is ready to be committed, even if there is some obscure issue. A 99% working feature is better than 0% working feature. And I still have not been about to rule out ME. Maybe I was having a bad day and I was doing something stupid.

Nice work Junyor

Fix checked in on the DRUPAL-5 branch.

@NaX: Your code clean-up patch is now http://drupal.org/node/226286.