Closed Bug 326337 Opened 19 years ago Closed 17 years ago

XMLHttpRequest.responseXML permission denied if document.domain set

Categories

(Core :: XML, defect)

Product:
Core
Component:
XML
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9alpha8

People

(Reporter: soconnor, Assigned: peterv)

References

Details

Attachments

(1 file, 1 obsolete file)

v2
(deleted), patch
jst
: review+
bzbarsky
: superreview+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 I am trying to use XMLHttpRequest to retrieve an XMLDocument through a hidden iframe on a different subdomain. The XMLHttpRequest object works fine. If I try and access the XML document through .responseXML I get a JS error in the JS console: "Error: uncaught exception: Permission denied to get property XMLDocument.documentElement" I can't add a testcase to bugzilla since it the single origin policy will only allow requests to the same domain. However here is a reduced testcase that can be tested locally: <html><head><script type="text/javascript"> document.domain = document.domain; var req = new XMLHttpRequest(); req.open("GET", 'http://subdomain.yourdomain.com/test.xml', false); req.send(null); alert(req.responseXML.documentElement); </script></head><body></body></html> Removing the first line ('document.domain = document.domain;') works. Note it that a work around in 1.5.0.1 is to parse the responseText: var doc = (new DOMParser()).parseFromString(req.responseText, "text/xml"); Reproducible: Always Steps to Reproduce: 1. Save testcase locally 2. Create faux xml document 3. Load page Actual Results: JS Permission Exception Expected Results: XMLDocument node
Related to/duplicate of bug 229711 -> bug 290100?
(In reply to comment #1) > Related to/duplicate of bug 229711 -> bug 290100? Not a duplicate.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I ran into the same issue - workaround suggested worked in the mean time. Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.1) Gecko/20060301 Firefox/1.5.0.1
I ran into the same issue on windows. a test-case can be found here http://app.lightstreamer.com/testMode/xmlDomain/?domain=ON to see the code in action without the setting of the domain, check http://app.lightstreamer.com/testMode/xmlDomain/
This defect is quite obvious and ugly. There are so many people experiencing this issue. I think the severity should be raised to Blocker
Blocks: tibco
The description of this bug should be changed to say all platforms since it affects more than just Mac. That change might get a better response from Mozilla developers.
(In reply to comment #6) > The description of this bug should be changed to say all platforms since it > affects more than just Mac. That change might get a better response from > Mozilla developers. Updated 'Hardware' and 'OS' to 'All'.
OS: Mac OS X → All
Hardware: Macintosh → All
A friend of mine asked that this be nominated. Software his company is building is broken due to this bug. If anyone can patch this, it'll be nice to get into the 1.8 branch, but if not, at least we can try to fix this for Firefox 3.
Flags: blocking1.9?
Flags: blocking1.8.1.5?
Peter, could you take a look at this. This would be very nice to get fixed since it's a pretty stupid bug. But if we get too close to ship without a patch it's likely to get minused. bz, would it work to give the document created by XHR the *same* principal as the loading document? That way any document.domain changes should not cause problems.
Assignee: xml → peterv
Flags: blocking1.9? → blocking1.9+
> bz, would it work to give the document created by XHR the *same* principal as > the loading document? I think so, as long as we don't do it for cross-domain XMLHttpRequests. See also discussion in bug 317240.
I suggest that Severity should be raised to major. This bug prevents using FX for creating same-primary-domain, but multiple host mashups with XML services called with XHR. That's a fairly major market trend to be constraining. I concur with the point the cross-(primary)-domain should remain restriced.
Attached patch v1 (obsolete) (deleted) — — Splinter Review
This fixes the testcase, but need to think about it some more. (In reply to comment #10) > I think so, as long as we don't do it for cross-domain XMLHttpRequests. See > also discussion in bug 317240. I'm not sure how cross-domain XMLHttpRequests would work then, it seems like the caller of the XMLHttpRequest should be able to access the loaded document?
> I'm not sure how cross-domain XMLHttpRequests would work then Good point. I guess we should try doing this across the board and see... And set some security folks to banging on it. The fix does seem like the right approach, fwiw. But what principal do we end up with if code in window A calls an XMLHttpRequest off window B? What principal do we _want_ to end up with?
Target Milestone: --- → mozilla1.9alpha6
(In reply to comment #14) > The fix does seem like the right approach, fwiw. But what principal do we end > up with if code in window A calls an XMLHttpRequest off window B? What > principal do we _want_ to end up with? With this patch we get the principal of window A. The other patch I had in mind (using GetDocumentFromCaller instead of GetSubjectPrincipal) would get the principal of window B. I think we actually want the principal of window B, that way you don't have access to the content of the responseXML document when you don't have access to the responseXML property. Make sense?
Yeah, that would make a lot of sense to me.
Attached patch v2 (deleted) — — Splinter Review
Attachment #268082 - Attachment is obsolete: true
Attachment #268786 - Flags: superreview?(bzbarsky)
Attachment #268786 - Flags: review?(jst)
Comment on attachment 268786 [details] [diff] [review] v2 Makes sense.
Attachment #268786 - Flags: superreview?(bzbarsky) → superreview+
Flags: blocking1.8.1.5? → wanted1.8.1.x+
punting remaining a6 bugs to b1, all of these shipped in a5, so we're at least no worse off by doing so.
Target Milestone: mozilla1.9alpha6 → mozilla1.9beta1
Attachment #268786 - Flags: review?(jst) → review+
Depends on: 386719
According to bonsai this patch landed and it appears to have caused bug 386719 and bug 386719.
> bug 386719 and bug 386719 Dave, it looks like you wrote the same bug number twice. Was there another bug you had in mind?
Bah, I blame our faulty clipboard! I meant bug 386656.
Depends on: 386656
No longer depends on: 386719
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Depends on: 390219
(In reply to comment #0) > I can't add a testcase to bugzilla since it the single origin policy will only > allow requests to the same domain. Séamus: in the possibly-unlikely situation that you ever need to do this again (or anyone else reading, for that matter), note bug 332179. That should be enough to do any cross-origin testing that's okay with only doing subdomain testing, with a little pain. :-)
Flags: in-testsuite?
The following code for some reason does not work in Firefox 2.x. It does work however in IE and Opera. The code is found within an iframe and I am trying to access the document object of the parent without success in Firefox. The parent document is located at http://mysite.com (domain is mysite.com) The iframe document is located at http://images.mysite.com (I have used javascript to set the domain to mysite.com) iFrame Code : <script language="javascript"> document.domain = "mysite.com"; var par = window.parent.document; par.getElementById('alert_user').innerHTML = "Select an image"; </script> The script basically stops when it hits the par.getElement line in Firefox. Any help with issue would be appreciated,
That has nothing to do with this bug. But make sure the parent is also setting document.domain to that value.
I think this is relevant as the problem is with accessing other document objects on other domains. Per my example, both domains are set to mysite.com. The parent url is http://mysite.com, thus the domain is mysite.com. The iframe domain is set in javascript to mysite.com.
Blocks: 445890
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: