SecurePages integration issue
| Project: | Secure Pages |
| Version: | HEAD |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Quick note on what you may or may not consider a bug.
When using the SecurePages module for SSL support, by default all /node/add/* pages are SSL-protected. I am using a content type with a single CCK nodereference field with the nodeexplorer module, with modal to do the pop-up. I'm using Modal 1.2 code with jquery update and jquery UI 1.6.
The initial content window was loading, but then I found that I encountered this in Firebug console:
Permission denied to get property Window.Drupal
Specifically, it's calling out child.js line 25 with this trace:
modalFrameChild()(Document Required)child.js?L (line 25)
(?)()()drupal.js?L (line 42)
nodeName()(Object, function(), undefined)jquery.min.js?L (line 20)
attachBehaviors()(Document Required)drupal.js?L (line 41)
(?)()()drupal.js?L (line 276)
onreadystatechange()()jquery.min.js?L (line 27)
onreadystatechange()()jquery.min.js?L (line 27)
nodeName()([function(), function(), function()], function(), undefined)jquery.min.js?L (line 21)
onreadystatechange()()jquery.min.js?L (line 27)
[Break on this error] if (!self.isObject(parent.Drupal) || !...lf.isObject(parent.Drupal.modalFrame)) {I then disabled SecurePages so /node/add/* was http only, and re-tried it. No problems at all - the windows appear normally. I found another post that talks about the 'same origin' policy whereby the hostname and protocol should match. I'm guessing that this somehow violates that policy which is why it stops it from working.
SecurePages seems to do lots of redirects between http and https, whereby even though the initial /node/add/mycontenttype is an https page this module may be posting the data back via http, and then securepages takes over and tries to convert it to https and it breaks.
I hope this isn't too rambling of an issue but it seemed worthwhile to at least bring it up.
Thanks!
#1
As far as I can tell, the parent window and modal dialog should open using the same URL protocol. If that's not the case, then we may need to find why that happens and fix it. ...or? suggestions?
It seems to me it is the job of the module that uses Modal Frame API to give it the correct URL.
#2
It seems to me it is the job of the module that uses Modal Frame API to give it the correct URL. So, from the point of view of the Modal Frame API, this issue is "by design" here. The parent window must have access to the child window.
It is the calling module that should give a URL that matches the browser context so it doesn't generate security related errors and/or alerts.
#3
Since you have written a nice report, this issue could be transfered to the queue of the calling module, but I'm not sure which one it is.
#4
Thanks Markus. If that's the case, I suspect we would want to redirect this to the Nodereference Explorer module as that is what is calling Modal Frame. I'll update the issue and change status to active in the event the NE author has comments/ideas.
#5
Another possible approach for this issue: Maybe the securepages module needs to alter the URLs defined to be secure in a way that's transparent to other modules, but this affects the design of the securepages module.
I'm not sure if it is possible, just guessing, but maybe the securepages module should alter the menu paths using hook_menu_alter() or something on that direction. The idea would be to try to generate the correct URL as a result of l(), url(), goto(), etc., so that modules using these functions don't need to care about securepages module. If that was possible, then it would help reduce performance issues because there would be a lot less redirections to do.
#6
On the user interface/application level we do not want to deal with security tasks (remember the OSI model?). Support should be transparent as described in #5.
Providing the correct URL by calling f. e. the url() function is good but may not be sufficient. What about Ajax requests where the server path is computed on the client side? We would also need some JavaScript implementation.
#7
Basically to resolve this the issue is that the modal window is being accessing a url which is not protected and being redirected to a http page.
Just work out what the path is and add it to the ignore list.
#8
It is possible to add the path to the ignore list. That works fine, however since the path is /node/add/mycontenttype and /node/NID/edit, I'm basically removing SecurePages from the majority of the pages I want to protect. My goal is to fix the modalframe/nodereference module so it can be used with SecurePages.
After a bit more reading, it appears that the child.js script is violating the Same Origin policy because SecurePages has switched modes underneath it. So now the trick is to see what can be done in the script to properly detect what the parent page is being served as (http or https) and then making sure to come back with the same protocol. I have made quite a bit of use with the securepages_is_secure PHP function to tell if a page is secure or not and take specific actions, but I can't seem to find an easy snippet of code to do the same thing for Javascript. After a bunch of Googling, I came across this:
var loc = new String(window.parent.document.location);if (loc.indexOf("https://")!= -1)
prefix = "https://";
else
prefix = "http://";
I also saw this:
var prefix = window.parent.document.location.protocol + '//';var url = 'site.com/';
Can someone with more Javascript knowledge than me please chime in with your thoughts? Do you think one of the above approaches would work? Or am I missing the solution? Thanks in advance.