Closed Bug 408098 Opened 17 years ago Closed 16 years ago

Implement XMLHttpRequest cross-site spec changes

Categories

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

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: bzbarsky, Assigned: sicking)

References

Details

From bug 389508 comment 42:

Anne van Kesteren   2007-12-12 06:23:57 PST

The API for cross-site non-GET requests has changed. Before Firefox 3 is
released this should probably be implemented along with the other requirements.

http://dev.w3.org/2006/webapi/XMLHttpRequest-2/
http://dev.w3.org/2006/waf/access-control/
Flags: blocking1.9?
And might I say that implementing unstable draft specs is a huge pain?  :(
Summary: Implement XMLHttpRequest spec changes → Implement XMLHttpRequest cross-site spec changes
(FWIW, Jonas has agreed with the design changes. Given that the WG was aware of the implementation work he was explicitly asked about this change.)
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Is this different from bug 397879?
Yes, we also need to send a no-cache header. And preferably build a local cache that is keyed off of all relevant headers.

Upping this to P1 as we really should fix this for next beta.
Assignee: nobody → jonas
Priority: P2 → P1
And implement method on <?access-control?> and Access-Control.
OS: Mac OS X → All
Hardware: PC → All
Sicking - we doin ok here?
There are things left, mostly due to a new feature that was recently added (hopefully last one). Filed bug 416957 on that.

There's also been some changes to the headers, so i filed bug 416958 on that.
Depends on: 416957, 416958
Should I file a bug on removing deny support or is that covered somewhere?
Depends on: 416968
We're not doing cross-site XHR for this release due to security concerns :(
Flags: blocking1.9+ → blocking1.9-
Can we elaborate on that somewhere?  I thought this was a _real_ blocker, in that we would hold the release for it, and we've certainly been advertising it to developers as a done deal.  If nothing else, we're going to need help explaining to them in more detail than "security concerns" (concerns with our implementation? concerns with the inherent semantics of the spec?) to defuse things.
With the WHAT-WG postMessage API, one can construct communicating windows to do cross-domain XHR anyway. That gives some defense in not sharing a DOM, mixing DOM data loaded from different domains. Is that sufficient reason for requiring users to load a JS library constructing such communicating windows/iframes in order to do cross-site XHR?

/be
How does my client-side app construct a window that has an origin of graphs.mozilla.org and put my own script in it to listen to postMessage and XHR for me?  That sounds like a major security model violation, if so.
The two sides of the postMessage channel need to cooperate, yeah -- that's the real defensive win compared to native cross-site XHR.

/be
So that means that any site that wants to permit people to load data from it needs to serve up a page from a well-known URL that implements some postMessage protocol?  That seems like pretty painful and unlikely to take off at useful scale.
I'll ask, because we'll be asked for sure: are the security characteristics of what Flash does (well-known file per site, etc.) better than the W3C proposal?  Are there security liabilities associated with the model Flash has that make it inappropriate for us to just adopt?
Flash is worse, I'm told. Also note that for cross-site XHR the target site needs to cooperate too. It has to explicitly allow access from the request origin ("Access-Control: allow <example.org>" for origin example.org).
Yes, but there's a specification for that, and it's a lot easier to do it than to write the postMessage recipient page and tell people how to find it for a given service.
There's a spec for postMessage too... And regarding simplicity, I guess that's true, but with copy & paste. :-)
Copy & paste and reimplementing the location patterns and method restrictions and such, no?
Shaver, please: Ajax libraries. Users don't have to reinvent wheels these days.

Ok, I'm not advocating a postMessage-based scheme, just repeating loose talk from around the office yesterday. Point is that different domains can communicate in a postMessage-equipped browser. Does that reduce phear of cross-domain XHR?

Giving developers more rope is the way of the web, but I admit it's early and we would like to avoid taking the first cdXHR bath.

Anne, what are Opera's plans, can you say?

/be
We want cross-site XMLHttpRequest, but it's too late for 9.5.
(In reply to comment #11)
> We're not doing cross-site XHR for this release due to security concerns :(

Was this a decision made openly, with a newsgroup thread? I'm not throwing stones, but I just heard about it yesterday or the day before, and obviously shaver only heard it here. What's the rationale, in this sense: under what conditions would we ship it, where the conditions don't hold today?

/be
Ok, after talking to sicking (who reminded me the objections were at the 2nd open security review meeting -- sorry for doubting), here's what I think:

* We shouldn't pull cross-site XHR for bad reasons, or vague reasons, or we won't know when to push it back into a release. We need to agree on what constitutes a sound reason for not including this feature.

* Sicking says there's high likelihood of the spec changing (see bug 389508 comment 42 too). He also thought we might force the spec to converge by shipping, which is a bad sign for the committee IMHO.

* There's fear about cookie infrastructure being reused in leaky ways, which is a good concern, but either we give 'em rope with warning labels and good docs, or we are losing. Give 'em rope is the way of the web, and indeed with more work and WHAT-WG postMessage, there's other rope to use anyway.

* dbaron had more thoughts on cookie threats that I can't represent here, but it might be useful to folks if he did.

* Jesse and I seemed to be agreeing that the spec more or less as-is could make the world a better place, by reducing password re-prompting and script injection hacks. In other words, there is likelihood of better security, but it's hard to weigh this against the risk of cookie abuses and other mistakes.

* Sicking said something about features being pushed into the spec at this late date that I do not remember. Performance scaling concerns are fine to fix before finalizing, but please save the features for a successor standard. I'm preaching to the wrong choir here, I'm sure.

All of this sums up to Do Not Ship Yet. I'd rather we ship JSONRequest, which is free of cookies by design and which has a stable spec. See bug 360666.

/be
Apart from an issue around setting request headers I'm not sure what sicking is referring to... We actually dropped features on request of Mozilla. I agree that the specification changing in the last month or so has not been ideal. The reason for that is that it starting getting attention pretty late in the game, which is unfortunate.

I'm not really convinced that's enough reason to introduce a new (limited) network API though.
(In reply to comment #25)
> * dbaron had more thoughts on cookie threats that I can't represent here, but
> it might be useful to folks if he did.

I think they added up to that I wasn't convinced by the arguments on either side.  In other words, I haven't been convinced that there are good use cases where cookies can be useful without the author shooting himself in the foot, and I haven't been convinced that allowing cookies is harmful either (at least given appropriately clear documentation on what the risks are).
(In reply to comment #25)
> All of this sums up to Do Not Ship Yet. I'd rather we ship JSONRequest, which
> is free of cookies by design and which has a stable spec. See bug 360666.

Should that bug be marked wanted-next?
Should *this* bug be marked wanted-next?
Flags: wanted-next+
Depends on: 424923
This bug became bug 389508 again, it seems.
This was done as part of bug 389508
Status: NEW → RESOLVED
Closed: 16 years ago
Depends on: xxx
Resolution: --- → FIXED
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.