Closed
Bug 386823
Opened 18 years ago
Closed 17 years ago
XMLHttpRequest gets wrong principal if no JS on stack
Categories
(Core :: XML, defect, P4)
Core
XML
Tracking
()
RESOLVED
FIXED
People
(Reporter: peterv, Assigned: sicking)
References
Details
Follow-up to bug 386656 (see bug 386656, comment 6). We should do the equivalent of what bug 332840 fixed for DOMParser.
Comment 1•18 years ago
|
||
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....
Assignee | ||
Comment 2•18 years ago
|
||
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?
Comment 3•18 years ago
|
||
Sounds like the nsIJSNativeInitializer setup DOMParser uses would work, at least if the |cx| there is windowB in the above case.
Comment 4•18 years ago
|
||
Also note that URI resolving happens on open(), not send(). (Including security exceptions.)
Comment 5•17 years ago
|
||
Better safe than sorry :) Blocking on this, should be pretty straight forward.
Assignee: nobody → jonas
Flags: blocking1.9? → blocking1.9+
Comment 6•17 years ago
|
||
(In bug 372964 XHR gets always bound to a window)
Comment 7•17 years ago
|
||
That's not reasonable for JS components. No windows there.
Comment 8•17 years ago
|
||
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).
Comment 9•17 years ago
|
||
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.
Assignee | ||
Updated•17 years ago
|
Priority: -- → P4
Comment 10•17 years ago
|
||
I assume we want here something smaller than bug 372964, something less riskier, like bug 332840?
Assignee | ||
Comment 11•17 years ago
|
||
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.
Assignee | ||
Comment 12•17 years ago
|
||
C++ callers would then be responsible for initializing with the window and principal.
Comment 13•17 years ago
|
||
What sicking said, absolutely.
Comment 14•17 years ago
|
||
FIXED per Jonas...
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Updated•17 years ago
|
Flags: in-testsuite?
You need to log in
before you can comment on or make changes to this bug.
Description
•