Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Working with Mobile Tools or a multisite setup easily leads to a situation, where you not only have the situation of securing some paths for one domain, but for at least two.
Consider the following example scenario (see http://drupal.org/node/1219986 ):
- site is located at http://www.abc.com/
- certain paths are automatically changed to https://www.abc.com/ by secure pages module
- site uses http://m.abc.com for mobile version
- certain paths (not necessarily the same as for the web version) need to be redirected to https://m.abc.com/
I think we'd need a complete set of current input fields on the backend side for each pair of secure / insecure base urls and some logic code to do proper domain detection and url switching.
Comment | File | Size | Author |
---|---|---|---|
#6 | 0001-Corrections-to-the-logic-in-secure-pages.patch | 1.93 KB | Nigel Cunningham |
Comments
Comment #1
grendzy CreditAttribution: grendzy commentedFrom the information so far, it's not totally clear what the use case is. Could you provide some specific examples of a path that would need domain-specific settings, and the reason why? I'm only vaguely acquainted with the mobile tools module.
Second, I do have a few ideas for how you might achieve your goal without needing to modify the module:
.
Comment #2
Anonymous (not verified) CreditAttribution: Anonymous commentedThank you for your support!
I thought through your suggestions and did some testing and this is what I came up with:
In a few days we should be sure about whether or not this solution is stable enough, even for planned further extensions. I'll give some additional feedback shortly.
Thanks again for your support, Dylan. We really appreciate it!
Comment #3
grendzy CreditAttribution: grendzy commentedGlad to help. As an aside, you can leave securepages_basepath and securepages_basepath_ssl blank (this is how I normally use the module), and the redirects will always use the current host, switching only the protocol. IIRC the host name is derived from the global $base_url, which is likewise automatically detected by Drupal if you don't set it in settings.php.
Whatever you're planning for in the future, do be aware that settings.php is loaded very early during bootstrap - thats why this trick works - so it's bare-metal PHP; none of the Drupal API is available yet.
Comment #4
wxman CreditAttribution: wxman commentedI'm glad I found this thread. I've been trying to figure out how to fix my login problem. We do have an SSL cert and I set the standard login page to be https://www.abc.com/user. When I try to log in using my phone, the mobile tools wants to keep switching it to http://m.abc.com/user. The phone browser keeps switching back and forth until it just errors out. I have my secure pages set to:
user/*/edit
user/*/edit/*
user/*/password
user/register
user/password
user
I tried the settings.php trick, but it didn't work.
I'd like to keep the login page https even on the mobile. It still isn't letting me log on from a mobile device. Any ideas?
Comment #5
rolando.isidoro CreditAttribution: rolando.isidoro commentedHi, here's another example of the same issue.
I'm using Secure Pages on an OpenSholar (OS) installation to enable HTTPS authentication. One of OS' features is the ability to define custom domains for its websites so that a site with an original URL http://domain.com/abc could be assigned a new custom domain like http://customdomain.com.
Since Secure Pages only allows one NON-SECURE BASE URL and one SECURE BASE URL, when I access the login form on http://customdomain.com/user/login the action value for the form is in fact http://domain.com/user, on submit I don't get logged into the sub-domain site, thus preventing me from accessing the OS control panel.
Comment #6
Nigel CunninghamHere's a patch against 7.x (apologies for updating the version) that addresses the failure to check whether the base_url matches the secure pages URL. This was used for a SalsaDigital customer so that http://example.net, https://example.net and http://example.com can all be redirected to http://example.com.
It has some overlap with https://www.drupal.org/node/566632 since I also needed to address that issue for the customer for whom this was prepared.