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 ):

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.

CommentFileSizeAuthor
#6 0001-Corrections-to-the-logic-in-secure-pages.patch1.93 KBnigelcunningham

Comments

grendzy’s picture

grendzy commented

From 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:

  • just roll with it, and "over-protect" your pages. SSL is really cheap in 2011, so perhaps your client can live with having a few mobile pages encrypted that don't really need it.
  • Try to make the paths distinct when they need differentiation - like abc.com/super-secret-stuff vs m.abc.com/less-secret-stuff
  • If per-domain settings turns out to be the best solution for your project, you can manipulate the value of $conf['securepages_pages'] by placing logic in settings.php (example below)

    • . 

// settings.php
if ($_SERVER['HTTP_HOST'] == 'm.abc.com') {
  $conf['securepages_pages'] = "secrets\nmore-secrets";
}
Anonymous’s picture

Anonymous (not verified) commented

Thank you for your support!

I thought through your suggestions and did some testing and this is what I came up with:

  • "over-protection" is not an option here as we would have to do it both for the new mobile site as well as the existing desktop site and it is hard to foresee the effects on seo for the existing site. If both sites were new, this would definitely be a way to go.
  • Distinct paths would be an option but requiring quite some work in our case. And every time you extend one site you'd have to make sure not to get into the way of things on the other.
  • Adding some logic to settings.php finally seems to do the trick (I'm not quite finished with testing). In our case we like to leave paths the same for the desktop and mobile site and therefore don't change securepages_pages but instead change the values of securepages_basepath and securepages_basepath_ssl in settings.php in dependence of the HTTP_HOST.

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!

grendzy’s picture

grendzy commented

Glad 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.

wxman’s picture

wxman commented

I'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. 

if ($_SERVER['HTTP_HOST'] == 'm.abc.com') {
  $conf['securepages_pages'] = "user";
}

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?

rolando.isidoro’s picture

rolando.isidoro commented

Hi, 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.

nigelcunningham’s picture

nigelcunningham commented
Version: 6.x-1.9 » 7.x-1.x-dev
Issue summary: View changes
Status: Active » Needs review
StatusFileSize
new 0001-Corrections-to-the-logic-in-secure-pages.patch1.93 KB

Here'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.

astonvictor’s picture

astonvictor commented
Status: Needs review » Closed (outdated)

D7 reached its EOL back in January 2025, and there is no active release for D7 for this module anymore.
Development or support is not planned for D7. All D7-related issues are marked as outdated in a bunch.

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.