You need to log in before you can comment on or make changes to this bug.
Tested in Netscape 7.02 and Internet Explorer 6.0.28. The error happens when I open the BoundingBoxPopup from a Chameleon webpage. When I open the Popup window the initial bounding box values are blank (when they should be filled in) and when I enter values to zoom on and click Zoom nothing happens. When I first open the window I get the following error in the JavaScript Console: Error: uncaught exception: Permission denied to get property Window.getMapExtents Then when I click on the Zoom button I get the following error: Error: uncaught exception: Permission denied to get property Window.applyBoundingBox The Chameleon application resides on a PC running Linux. The BoundingBoxPopup.widget.php version is v 1.26. The error only happens on certain PCs so I assume it's some kind of security setting on those computers.
Scott can you please try to reproduce this error using the latest version I sent to you this morning?
set release target for FUTURE
This problem ended up having its roots in the chameleon.xml document. In the document I had the web_server_path defined using the specific IP address of the server: <param-name>web_server_path</param-name> <param-value>http://132.156.96.225/chameleon/</param-value> When I was testing I was testing using the server name in the URL ie: http://www.servername.com/applicationName When I changed that URL to be the IP address ie: http://132.156.96.225/applicationName I no longer had this problem. It seems that chameleon is reading the absolute path from the XML document and some JavaScript wasn't working if the URL path didn't match exactly. I've since changed the <param-value> in the XML document to the relative value of "/chameleon/" and the application is working.
documentation issue - related content from mailing list: this problem is not easily solved. Chameleon session management attempts to prevent session hijacking (or fixation) for security reasons ... what this means is that when you start a session, the URL that you connected from is recorded in the session. When subsequent requests arrive, the current URL is tested against the one in the session. If they don't match, the session is immediately terminated. When you include an absolute URL in the chameleon.xml file, this has a strange side effect because the session will record the URL that the user used to connect, but popups are launched using the URL from chameleon.xml. If they aren't the same, you end up with this problem. If you use a relative URL, then chameleon figures out the right host for popups from the URL the user is using. I think this is primarily a documentation issue, the way this works should be left as-is to allow for tighter security, but it should be clearly documented somewhere what the implications of using different configurations in chameleon.xml are. Thanks for finding this out and reporting it on the list. Until you brought this up, I hadn't really realized that this would happen. Seems obvious now ;)
Daniel has pointed out that I am actually wrong about the source of this issue, it actually doesn't have anything to do with the session code, it is a browser security constraint that prevents scripting between windows that apparently come from different hosts. There may also be a technical solution to this, which would be to rewrite the host part of the URL coming from the chameleon.xml (if it exists).
