NS_ERROR_FAILURE on XMLHttpRequest call when using expanded principals

RESOLVED INACTIVE

Status

()

Core
XPConnect
RESOLVED INACTIVE
6 years ago
4 days ago

People

(Reporter: ochameau, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
When using expanded principal list in sandboxes, XMLHttpRequest throws an NS_ERROR_FAILURE exception.

Here is a minimal testcase that can be run in scratchpad:
  let Cu = Components.utils;

  // Use new feature from bug 734891:
  let s = Cu.Sandbox([content.location.href, "http://bar.com"]);
  s.window = content;

  let js = "(" + function () {
    try {
      // This line is throwing:
      return window.XMLHttpRequest();
      // Can test this form too when you get a patch,
      // As we are using this more complex pattern in jetpack:
      return Function.prototype.apply.apply(
        window.XMLHttpRequest, 
        [window, []]
      );
    } catch(e) {
      return e;
    }
  } + ")()";

  let r = Cu.evalInSandbox(js, s)
  Cu.reportError(r);


I was able to spot this issue by running jetpack test on this branch:
  https://github.com/ochameau/addon-sdk/tree/cross-domain-content-script
This branch is using new feature from bug 734891.
You can run most important test like this:
  $ cd addon-sdk
  $ source bin/activate -or- bin\activate.bat
  $ cd packages/api-utils
  $ cfx test -v -f test-content-proxy -b /path/to/firefox
(Reporter)

Updated

6 years ago
Blocks: 734891
Ok so first of all why would you ever do something like this? In bug 734891 I added an optional xhr constructor to the sandbox (patch 5). Passing an XHR object like that and expecting that it can be used in a different compartment with a different principal is not the way to go. When you create an XHR object within the sandbox (you can do that if you set wantXHRConstructor option to true for the sandbox and simply call new XMLHttpRequest() inside the sandbox) it will have the expanded principal, and should just work.
(Reporter)

Comment 2

6 years ago
Oh I forgot about that wantXHRContrustor argument.

I can easily workaround this error with JS proxies, by catching all access to XMLHttpRequest property for all Window objects:
https://github.com/ochameau/addon-sdk/commit/57917a87425869a218eb8fc95ed15c72c911ed8a#L0R692

But I think we may want to get this fixed for JS proxies removal, bug 738244.
Various JS framework, like JQuery for ex, doesn't use XMLHttpRequest global, but window.XMLHttpRequest.
We should be able to fix that with code similar to this:
  // Do not use xraywrapper as we can't delete native properties (yet?)
  let proto = content.wrappedJSObject;
  delete proto.XMLHttpRequest;
  
  let s = Cu.Sandbox([content.location.href, "http://bar.com"],
                     { wantXHRConstructor: true, sandboxPrototype: proto });
  Cu.evalInSandbox("window.XMLHttpRequest = XMLHttpRequest;", s);

But then, if they use an iframe's XMLHttpRequest object, it will throw the same error.
(In reply to Alexandre Poirot (:ochameau) from comment #2)
> But then, if they use an iframe's XMLHttpRequest object, it will throw the
> same error.

So I think that you should be able to use an XMLHttpRequest object if your principal  subsumes the principal it was created with. So like in this case if your ExpandedPrincipal subsumes the principal of that iframe, it should be capable of using it. I will look into this why it does not work, I suspect another principal equal check somewhere instead of principal subsumes.
Summary: NS_ERROR_FAILURE on XMLHttpRequest call when using extanded principals → NS_ERROR_FAILURE on XMLHttpRequest call when using expanded principals

Comment 5

4 days ago
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 4 days ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.