This link to the Usenet archive on Google has an item with a lot of interesting info on Mozilla DOM stuff compiled into one place: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=eadeadc2.0207231411.50e602a4%40posting.google.com&rnum=1&prev=/groups%3Fq%3DxmlDoc.load%2Bnetscape%2Berror%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3Deadeadc2.0207231411.50e602a4%2540posting.google.com%26rnum%3D1 Just FYI if anyone's trying to get around similar stuff. Also, it may have been unclear from my first post, but I'm trying to parse an XML file returned as the result of a http call. It can work directly from a file or from input, but I can't get Mozilla to load an URL result as XML.
You're trying to load XML from a different domain, which I don't believe we allow, for security reasons.
Hm. Not sure how that adds to security. I could put the same logic bomb into a local URL or a file that could be there in a non-local domain. I guess there's some assumption here that code from a different domain name may be evil, but code from a local domain is trusted in some way? However, I don't really see the difference personally. If I'm a naughty webmaster, I could pull the same tricks either way...right? It seems more restrictive than secure to me IMHO.
> I guess there's some assumption here that code from a different domain name may > be evil, but code from a local domain is trusted in some way? No. What is being protected here is the user's ability to communicate with the "different domain" without you reading the data. If you could make requests to the "different domain" that look like the user making a request and then read the data, that would be disastrous (thing "different domain" == "user's bank's web site"). So the idea here is not to prevent the browser from loading the content (you could load it in an iframe) but to prevent _you_ (and untrusted and presumed evil person) from getting at content that only the user should be able to get at. See http://sec.greymagic.com/adv/gm001-ns/ and the IE equivalent at http://www.xs4all.nl/~jkuperus/bug.htm for more information.
15 years ago
I'm seeing this in Mozilla on Linux; I have a folder system like this: main-folder vDesktopService - xml files created by the server vDesktopLogin - a html file loading the xml files from xml It's obvious the xml is coming from the same server as the html, but I get the error: Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMXMLDocument.load]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: http://vdesktop.us/vdesktoplogin/webservice.js :: callService :: line 46" data: no] What's going wrong here? This cannot possible be a security problem as the xml is coming from the same server
Joris, I suspect in your case this happens because your script is at vdesktop.us while the script tries to load a file from www.vdesktop.us. String comparing these two hosts shows they are different, and the security manager will block it. Try relative URLs (i.e. skip the host part), or make sure the host names really are the same.
So the only issue we have is that we should have a more decriptive error message for a security error? Since document.load() will be in DOM Level 3, I think we could reuse the DOM access denied error messages. Let me know if you think something else is needed.
15 years ago
Created attachment 114724 [details] [diff] [review] Proposed fix No need to throw exception here, CAPS will do it for us. There are no C++ callers of this method in Mozilla either, so should be cool for everyone.
After the fix the user will now see this in JS console (we do this for XMLHttpRequest.open as well): Error: uncaught exception: Permission denied to call method XMLDocument.load
Comment on attachment 114724 [details] [diff] [review] Proposed fix r=mstoltz on this fix. Returning OK instead of FAILURE should make the more descriptive error message propagate.
15 years ago
Comment on attachment 114724 [details] [diff] [review] Proposed fix Could you add a comment at the return or in the header or both to point out that if JS code calls C++ code that calls this code then the C++ caller doesn't get notified about the error.
Sure, I'll add the comment.
Fixed. I added the following comment to the C++ code: // We need to return success here so that JS will get a proper exception // thrown later. Native calls should always result in CheckConnect() succeeding, // but in case JS calls C++ which calls this code the exception might be lost.