Change $base_url to https:// if explicitly set to http:// by settings.php

This really doesn't feel like a core bug at all. If secure pages messes-up with the URLs, it should also mess up with $base_url.

If you set $base_url in your settings.php, Drupal will respect that (including the protocol). Secure Page could override $base_url if it wants to.

But as far as Drupal is concerned, there is nothing wrong with this behavior.

conf_init should use the correct URL scheme when a request goes over https and $base_url is NOT explicitly set in settings.php. If not, there's a bug in conf_init.

Can you confirm the problem occurs on an install that does NOT have $base_url set in settings.php?

The fundamental issue is that the AHAH/AJAX callback must exist.

If you're on https://example.com/somepage, which has an AHAH feature, it's going to look for /somecallback (which has been set up with #ahah). If that callback doesn't exist, you get a 404. Well, if securepages is converting "somepage" to https, but not handling "somecallback", then you have a 404.

I think the bottom line is if you're using securepages and AHAH, you basically need to either:

1. Convert the whole site to https

or

2. Convert all AJAX pages and all AJAX callbacks to https

or

3. Convert all AJAX pages and all AJAX callbacks to not be https.

I don't actually see this as a bug in anything, but an unintended consequence of the way Securepages changes only some URLs on a site to a different scheme.

Note that just adding/excluding "*/ajax/*" is in no way adequate, as there is no way to know that all #ahah['path'] have "/ajax/" in them - #ahah['path'] is free form.

In Drupal 7, nearly all AJAX forms go through /system/ajax, so you have higher chance of success there. But you still have a problem: SecurePages won't let you map a class of URLs as "always the same as the calling page" or something like that.

Well. Anyway, except if we have more information proving otherwise, this is a Secure Pages issue.

rfay's description makes sense to me. We experienced this issue on our site with Ubercart. I don't think it is Drupal core's responsibility to solve this. Rather, the user of SecurePages must take care to either explicitly exclude or include all AJAX paths from https.

Still, this should be documented, and a list of the most common (Views, Panels, Ubercart, etc.) should be created, if it doesn't exist already.

Personally, I find that this issue makes it too difficult to use Secure Pages for the entire /admin section, since there are too many paths to worry about. So I restrict its use to the Ubercart store specifically. However, this definitely limits the module's usefulness.

Note that when $base_url is not set, Drupal core will automatically set it to https:// if on HTTPS. See bootstrap.inc's conf_init.

Secure Pages should mimic this behavior, even if the user has set the $base_url as "http://www.example.com" in their settings.php file. There are lot people opening issues that are related to $base_url set to http, and and this module can resolve it rather simply. Let's make this module work out-of-the-box!

I propose that Secure Pages checks if the user has http:// in the $base_url, then change it if on SSL. This will resolve all these issues about Ajax errors, etc.

Here is one solution. Add this on the very top of securepages.module:

// Change base_url to HTTPS ($base_url may be explicitly set by settings.php)
if (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == 'on') {
  global $base_url;
  $base_url = str_replace('http://', 'https://', $base_url);
}

That seems like a good solution. Thanks, Jonah.

@Jonah: Could you re-roll this as a patch, and thus I could test and mark RTBC?

Jonah's code in comment #10 above worked great for me and was quick and easy to get things fixed. (Thanks so much, Jonah!)

Has this been rolled into Dev or can it be soon?

Probably it would need to be made into a patch before the maintainer would be willing to commit. Sorry I don't have time atm.

#10 seems to be working for me. here's a patch for it.

D6.19
Securepages v6x-1.8

Confirming that #10 solves ajax errors.

Thanks for solution to very annoying problem!

Here is an updated version of the patch from #15. I moved it into hook_boot and changed the if statement to leverage the securepages_is_secure() function.

We also need to set $base_root correctly so pages are cached under their correct addresses in the cache table. This has caused weirdness when caching is enabled and $base_url is set - see my comment at http://drupal.org/node/587000#comment-4224126.

My patch there (http://drupal.org/node/587000#comment-4224320) takes a similar approach to #15 here, except it updates the URL using the existing securepages_baseurl function - allowing the $base_url to reflect the custom paths setting provided in the admin interface (as well as less code duplication).

I'll post an updated version of the patch (including $base_url and $base_root) shortly.

Thanks, David