Posted by leop on January 30, 2008 at 5:50pm
| Project: | Secure Login |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Here is a patch that solves two problems:
- The Secure Login module requires the user to make changes to
settings.phpin order to refer users to the insecure page. In this patch I propose a solution that useshook_init()to change the$base_urlvariable depending on whether a login attempt was performed. To make this work, an additional (hidden) field was added to the login forms. In this fashion thesettings.phpfile doesn't have to be modified anymore. - When a user logged on from a secure site, while the
$base_urlwas set to the insecure site, the user would be redirected to the insecure site. In the patch this is solved. Users logging in on the secure site will always be redirected to the secure site,while users logging in on the insecure site can be redirected to the insecure site when this option is enabled. Redirecting users to the insecure site when necessary can be be enabled or disabled from the securelogin administration page.
The only thing that needs to be solved to make this module perfect is:
but this is really hard because there is no hook that can be called on unsuccessful logins.
Comments
#1
And the patch...
#2
Actually, there was a much simpler (and better) way to implement this patch. Referring users back to the original host after sending the password to the secure host is now better implemented. For example, if the user logs on from
http://mysite.com, the password will be sent usinghttps://mysite.com, and the user can be redirected to the original address athttp://mysite.com, depending on the admin settings. If the user logs on fromhttps://mysite.com, the password will be sent usinghttps://mysite.com, and the user will stay inhttps://mysite.com.Also, it is not necessary anymore to actually specify the secure hostname; if it is not specified, the https version of the current host ($base_url) will be used. This allows for accessing the website under multiple hostnames (aliases), however the secure hostname and the insecure hostname must still match. To achive this, leave the secure URL field in the administrative page empty.
Furthermore http://drupal.org/node/177495 is partially solved, because a successful login after an unsuccessful login attempt will lead to the original host.
#3
again something went wrong with uploading the patch. Here it is.
#4
Oh no, #'s are not allowed in the filename. So again, here is the new patch...
#5
This is now implemented. Thanks for the patch! I've also decided to completely remove the secure base URL setting. Hopefully no-one will complain. :-)
#6
Close.