XMLHttpRequest gets wrong principal if no JS on stack

RESOLVED FIXED

Status

()

Core
XML
P4
normal
RESOLVED FIXED
11 years ago
10 years ago

People

(Reporter: peterv, Assigned: sicking)

Tracking

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +
wanted1.8.1.x ?
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
Follow-up to bug 386656 (see bug 386656, comment 6). We should do the equivalent of what bug 332840 fixed for DOMParser.
Except we should check what the XMLHttpRequest spec says about cross-window XMLHttpRequest() constructors.  And whether what send() does depends on the calling window or where the request was constructed.

Ideally, imo, we would grab all the security stuff once: at construction time.  And nix the script context business we have around there....
iirc the spec says to use the scope of the ctor that was used. So doing, in windowA, |new windowB.XMLHttpRequest()| would create an XHR with base and principal of windowB.
Flags: blocking1.9?
Sounds like the nsIJSNativeInitializer setup DOMParser uses would work, at least if the |cx| there is windowB in the above case.

Comment 4

11 years ago
Also note that URI resolving happens on open(), not send(). (Including security exceptions.)
Better safe than sorry :) Blocking on this, should be pretty straight forward.
Assignee: nobody → jonas
Flags: blocking1.9? → blocking1.9+
(In bug 372964 XHR gets always bound to a window)
That's not reasonable for JS components.  No windows there.
I know that is a problem. From the current XHR WD:
"When the XMLHttpRequest() constructor is invoked a persistent pointer to the 
associated Window object must be stored on the newly created object. This is 
the Window pointer. The associated Window object is the one of which the 
XMLHttpRequest constructor was invoked. This pointer must persist even if the 
browsing context in which the Window is located is destroyed (by removing it 
from a parent browsing context, for instance). "
So unless the spec changes, we'll have to bind xhr to window in the normal 
case, when xhr is used in web pages. For C++ or JS Components something else 
is needed. Like the Init method from bug 332840 :) (bug 372964 adds an Init 
method to XHR too, though, probably that should take different parameter).
Oh, sure.  That sounds good, yeah.  As long as everything we need off the window can be provided in some other way, life is good.
Priority: -- → P4
I assume we want here something smaller than bug 372964, something less riskier, like bug 332840?
What we should do here is to do what the XHR spec says and initialize the XHR with a window (and principal) when created. We can then use that principal always rather than constantly looking for a JS-stack whenever we need a security context or similar.
C++ callers would then be responsible for initializing with the window and principal.
What sicking said, absolutely.
Depends on: 403168
FIXED per Jonas...
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Flags: in-testsuite?
Fixed by the patch for bug 392322, to be exact.
Depends on: 392322
Do we need this one on the 1.8 branch as well?
Flags: wanted1.8.1.x?
You need to log in before you can comment on or make changes to this bug.