| Project: | Administration menu |
| Version: | 6.x-3.0-alpha1 |
| Component: | Documentation |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (works as designed) |
Issue Summary
I noticed this on one of my site. After firebug-ing it I found that it's a JS error (Permission denied) caused by an https page accessing a http site depending on the Secure Pages settings.
If the settings are, as the defaults, to "Make secure only the listed pages.", with the admin/* paths being the one secured, admin_menu AJAX request are against /js/admin_menu, thus falling back to http as per the other default setting "Switch back to http pages when there are no matches". and failing because of a JS permission denied error.
To fix this there might be a few things that can be done on Secure pages. I guess disabling "Switch back to http pages when there are no matches". would work but my preference was to add js/* to the Ignore pages field set of the Secure Pages module.
Comments
#1
#2
Also, I wasn't sure of what category use for this issue report, and not sure if this is something worth tweaked on admin_menu or not, or just document it. Please change categories if necessary.
#3
Adding js/* to secure pages ignore settings fixed this for me too. Thanks.
#4
I've read this issue multiple times in the meantime. I don't think we can actually do something about it.
In addition, the approach of securing a web site only partially is flawed IMHO. Either you request a page in HTTPS or you don't. If you do, all page requisites and links on that page should be secured as well.
#5
I don't think that adding js/* to the secure pages ignore list only partially secures the page. Adding the path to the ignore list only tells secure pages that it can serve either http OR https for those urls, it doesn't force it to use one or the other.
#6
I doubt there's a code solution, but I think it would be a good idea to at least mention it in the installation instructions. Firebug showed a GET request to a secure URL whether js/* was an ignored path or not, but adding it changed the response from a 302 Found to a 200 OK. That was what allowed the admin menu to show up.
#7
I also got a bug report for one of the modules I maintain about javascript problems when Secure Pages module is enabled, and I think this is business of the Secure Pages module that should tell Drupal to generate the correct URLs somehow. But no, it works performing redirections when the request reaches the server with a protocol that does not match the expected protocol, and this is bad design IMHO, the result of which is that users of this module are complaining to someone elses queue about it. What the Secure Pages module do, should be transparent, but no, it happens that all modules are incompatible with Secure Pages module, heh.
#8
The problem seems to be with jumping from http: to https: or from https: to http:
That being the case, the solution I've whipped up is to force secure pages to make the entire site be secure if the user is of a particular role (or uid 1)..
Maybe not ideal, but at least my admin menu is working, and will continue to do so for any users who will have it enabled (as I'll set their roles to force site-wide https too).
I've whipped up a patch for securepages that adds this functionality and a list of checkboxes on the securepages admin page to set which roles should have every page secure and which should not.
If anybody's interested I've attached that page here, drop it into your modules directory (whatever dir you've got the securepages directory in) and apply it...
In my case it was sites/all/modules/contrib as secure pages is installed at sites/all/modules/contrib/securepages
#9
Have you tried adding js/* to the ignore settings? That should fix it w/o the need of a patch?
#10
This is GREAT! I've been wrestling with this for AGES! Adding js/*.... yeesh... :)
#11
Subscribing for future reference. Adding
js/*works for 7.x as well.#12
subscribing for reference as well.