Closed Bug 641706 Opened 9 years ago Closed 9 years ago

Add (non-CORS) Cross-site XHR powers to SpecialPowers

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla5

People

(Reporter: sicking, Assigned: sicking)

References

Details

Attachments

(1 file)

We need to make it possible for mochitests to do cross-site XHR requests without relying on the CORS security model. There is a risk that this will require changes both on the C++ side as well as some code in SpecialPowers.

In general, XHR could use a lot of cleanup and simplification in how it handles security so I might do that as part of this.
Do you have an idea of how this should work? Would tests request permission to access specific domains? Would we just whitelist a set of domains that are okay to do cross-site requests to/from?
Tests would basically do:

xhr = SpecialPowers.getXSXHR();

and then just use "xhr" like a normal XHR object, except that it would be permitted to do cross-site requests.
I wonder if the SpecialPowers XHR could be just created in 
MessageManager context. That should give it chrome privileges, I think.
Perhaps we need to add something to XHR so that MessageManager context can
set the owner window. That way XHR could have system principal, but
the content page as owner.
Would an xhr created this way be able to set arbitrary request headers as well? It looks like that's something our tests tend to do.
Attached patch Patch to fixSplinter Review
This should do it. Passes on tryserver.

I do have a followup patch to get rid of nsIXMLHttpRequest.openRequest. But it's a bit messy so I'll file a followup for that.
Attachment #520304 - Flags: review?(Olli.Pettay)
(In reply to comment #5)
> Would an xhr created this way be able to set arbitrary request headers as well?
> It looks like that's something our tests tend to do.

Yes
Comment on attachment 520304 [details] [diff] [review]
Patch to fix

>     documentPrincipal = do_CreateInstance("@mozilla.org/nullprincipal;1", &rv);
>     NS_ENSURE_SUCCESS(rv, rv);
>   }
>+  else {

if () {
  ...
} else {
  ...
}
Attachment #520304 - Flags: review?(Olli.Pettay) → review+
Olli: I agree we ideally would want to be able to set the owner to the window which is using the "system XHR". However so far things seem to work without it.

One problem we have is that we currently have no way of exposing API on a DOM object only to chrome. We can always add a 'moz' prefixed function whose implementation checks the callers principal, but that's somewhat ugly.

Ideas welcome, or we can simply go with the current patch.
Awesome! When this lands, can you document it at https://developer.mozilla.org/en/SpecialPowers ?

RE: APIs just for chrome, presumably we could hand back a JS proxy that wrapped the real XHR and do some funny stuff there...
The patch should be enough for SpecialPowers, at least for now.

But could we have "nsISystemXHR" which would have bindToWindow(in nsIDOMWindow aOwner). Or, perhaps better to have nsIWindowBoundObject.
Then chrome js could QI to that and call bindToWindow(in nsIDOMWindow aWindow).
It would be up to the implementation of nsIWindowBoundObject
to check that bindToWindow doesn't work if the object is non-chrome.
In this case bindToWindow would do something only if mPrincipal is system
principal.

We could even make nsDOMEventTargetHelper to implement that interface
and move mPrincipal there. That way Websockets, IndexedDB, FileReader etc
could be easily bound to a window.
Checked in

http://hg.mozilla.org/mozilla-central/rev/132e89233cfa
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Can you add this to the SpecialPowers docs:
https://developer.mozilla.org/en/SpecialPowers

Specifically, if you can document what restrictions this special XHR object lifts vs. the standard XHR, that would be very useful.

Thanks for the patch!
Target Milestone: --- → mozilla5
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.