Closed Bug 326337 Opened 14 years ago Closed 12 years ago
Request .response XML permission denied if document .domain set
(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:18.104.22.168) Gecko/20060301 Firefox/22.214.171.124
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
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.
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.
13 years ago
Duplicate of this bug: 380025
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.
Depends on: 317240
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?
(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.
Comment on attachment 268786 [details] [diff] [review] v2 Makes sense.
Attachment #268786 - Flags: superreview?(bzbarsky) → superreview+
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
> 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.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
(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. :-)
That has nothing to do with this bug. But make sure the parent is also setting document.domain to that value.
You need to log in before you can comment on or make changes to this bug.