As discussed in #746264: Ajax error message on secure pages, when one is using HTTPS on their website, Ajax error messages are returned. For example, after enabling the Secure Pages module, I went to create a view. When I tired to add a Filter to my new view, I received the following error message:
An error occurred at http://www.my-domain.com/admin/build/views/ajax/add-item/my-view/default....
More precisely, the error occurs when I have Secure Pages enabled and on a https connection in /admin. I create a filter in my view, make my selection of which type of filter to add, and then click "add." Upon investigation with Firebug, without making any changes to the default settings of Secure Pages, when I click "add" I get a 404 status for the "Options Filter" located at "http://www.my-domain.com/admin/build/views/ajax/add-item/my-view/default..." when the URL should be coming from "https://...".
When I modify the Secure Pages module away from its default settings, and take out the directive to ignore "*/ajax/*", and try again, a 302 redirect is returned, as show by Firebug. Yet this is still enough to break the ajax request, as I get the same error message.
I received similar messages when I tried to add a Field.
The solution for me was in comment #11 in the issue linked to above, with 1 minor modification (adding 'www.' before 'mysite.com'):
$base_url = ((isset($_SERVER['HTTPS']) && $_SERVER['HTTPS']=='on') ? 'https://' : 'http://') . 'www.mysite.com';
However, as Fox rightly pointed out on IRC, putting the fix into $base_url is not a viable option for the public at large.
Comment | File | Size | Author |
---|---|---|---|
#17 | securepages-863562.patch | 723 bytes | d.clarke |
#15 | securepages-863562.patch | 561 bytes | hadsie |
Comments
Comment #1
Damien Tournoud CreditAttribution: Damien Tournoud commentedThis 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.
Comment #2
DavidWhite CreditAttribution: DavidWhite commentedI disagree, due to the comments made by merlinofchaos in the issue that I linked to in my original post (see comments #6 and #8). In addition, please see comment #3 in #566650: Views & Popup AJAX Do Not Work with SecurePages. I did my homework before submitting this; however, I suppose I could still be wrong.
But in both issues that I have linked to now, there are comments specifically mentioning that the problem remains when Secure Pages is turned off (but the site is using https by some other means). Note also that I am now using the $base_url fix on my current site, and secure pages is working with views as it should.
Comment #3
Damien Tournoud CreditAttribution: Damien Tournoud commentedIf 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.
Comment #4
Heine CreditAttribution: Heine commentedconf_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?
Comment #5
rfayThe 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.
Comment #6
Damien Tournoud CreditAttribution: Damien Tournoud commentedWell. Anyway, except if we have more information proving otherwise, this is a Secure Pages issue.
Comment #7
EvanDonovan CreditAttribution: EvanDonovan commentedrfay'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.
Comment #8
EvanDonovan CreditAttribution: EvanDonovan commentedPersonally, 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.
Comment #9
DavidWhite CreditAttribution: DavidWhite commentedAfter #3, Damien and I talked briefly on IRC, and I agreed and better understand the situation. Sorry that I haven't been able to respond to this again until now. I think my issue was that $base_url was specifically set. I am curious (and will try to test soon) as to how Secure Pages works when $base_url is not set. I agree (now) that this is not a core issue. However, I don't think that the issue is specifically related to Secure Pages, but to all implementations of HTTPS when $base_url is set - and this, I agree with EvanDonovan, needs to be better documented.
I'll try to do some testing soon and get back to you guys. Thanks for the comments and for your patience!
- David
Comment #10
Jonah Ellison CreditAttribution: Jonah Ellison commentedNote 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:
Comment #11
EvanDonovan CreditAttribution: EvanDonovan commentedThat seems like a good solution. Thanks, Jonah.
Comment #12
EvanDonovan CreditAttribution: EvanDonovan commented@Jonah: Could you re-roll this as a patch, and thus I could test and mark RTBC?
Comment #13
visualnotion CreditAttribution: visualnotion commentedJonah'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?
Comment #14
EvanDonovan CreditAttribution: EvanDonovan commentedProbably it would need to be made into a patch before the maintainer would be willing to commit. Sorry I don't have time atm.
Comment #15
hadsie CreditAttribution: hadsie commented#10 seems to be working for me. here's a patch for it.
Comment #16
WiredEscape CreditAttribution: WiredEscape commentedD6.19
Securepages v6x-1.8
Confirming that #10 solves ajax errors.
Thanks for solution to very annoying problem!
Comment #17
d.clarke CreditAttribution: d.clarke commentedHere 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.
Comment #18
dbassendine CreditAttribution: dbassendine commentedWe 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
Comment #19
ThirstySix CreditAttribution: ThirstySix as a volunteer and commented