This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In order to default to a more safe mode of operation EventSource should default to not sending credentials in cross-origin requests. This also has the advantage that it matches how XMLHttpRequest works. In order to opt-in to using credentials a constructor argument should be used. Something like the following WebIDL: dictionary EventSourceInit { boolean withCredentials = false; } [Constructor(DOMString url, optional EventSourceInit optParams)] interface EventSource : EventTarget { ... readonly boolean withCredentials; ... }; This also matches the conclusion we came to during the mozilla security review and is thus the solution we're for now planning on deploying (prefixed for now of course).
I would recommend not prefixing it. If we do add it, I'll make sure it's compatible with what Gecko does. That will reduce the time to market for the feature implemented consistently. Having said that, I really don't see how this improves security. As a client-to-server attack it's no more powerful than <img> today. As a foreign-server read attack, it only works with event streams, and then only if the server explicitly echoes the client origin. I don't see how not sending cookies improves matters. Event source resources will pretty much always have a script, which is where one could do the echo of the origin
In order to avoid repeating the whole discussion here, i'll just refer to https://bugzilla.mozilla.org/show_bug.cgi?id=664179#c18 I think we'd unprefix as soon as the spec is changed unless there's indication from other implementors that they disagree with this solution.
I'd prefer to default withCredentials to false just so server operators can use Access-Control-Allow-Origin: * without much hassle. The public mashup case is by far the most common and we should optimize for the common case.
Yup, that's what this bug is asking for too. Given that, it sounds like webkit would not mind going the same route as Gecko (in fact, might even prefer to do it). So unprefixing as soon as the spec is updated sounds doable.
The points raised in comment 1 were not raised in the Bugzilla bug, so IMHO they have not yet had a response. abarth: Can you give an example of a public mashup that would use this? So far literally all the use cases I've heard of are personalised, either based on cookies or user ID information in the URL. sicking: what does the prefixing solve?
> abarth: Can you give an example of a public mashup that would use this? First, any public data source, like stock information. Second, any API that uses OAuth for authorization (i.e., all of them): http://www.flickr.com/services/api/ https://dev.twitter.com/ http://developers.facebook.com/docs/reference/api/ Today, these APIs are generally request/response, but having a push-updated Twitter stream, for example, make a lot of sense. Given that most of these APIs are between by HTML and mobile applications, there is a strong design pressure to use something other than cookies to authorize requests. Even in web-only scenarios, you need to make sure the requesting site is authorized to receive a given user's information, which generally means cookies alone aren't enough. In fact, all the real examples I can find are either public or use OAuth to authorize requests.
(In reply to comment #1) > Having said that, I really don't see how this improves security. As a > client-to-server attack it's no more powerful than <img> today. As a > foreign-server read attack, it only works with event streams, and then only if > the server explicitly echoes the client origin. I don't see how not sending > cookies improves matters. This is not the concern. The concern is that people that want to share public data should be able to use the much safer credential-less CORS mode. This has at least two facets: * It means that the site doesn't have to worry about accidentally putting user specific contents in the event stream and then sharing that without the user's permission. * Not opting in to sharing more resources than needed. As CORS gains ground there will likely be server-side technologies which let's you configure policies separately from the scripts that build the response bodies. It'd be an easy mistake to set a directory to share with-cookies rather than set a resource to share with-cookies. > Plus, non-personalised streams are unlikely > to be common, so making it possible to return resources without cookies won't > affect many sites. You still have not shown data backing up this claim. > Also, note that this does match what XHR does. It uses the same underlying > CORS and 'fetch' technology. The only difference is that many of the knobs > are locked to a particular value. Indeed. The "knob" here makes an extremely big difference, so this argument isn't particularly convincing. > Not just withCredentials, by the way; also the > method, the payload, the HTTP headers on the request, etc. I don't think the > consistency argument holds water here. It makes the security model consistent. CORS really defines multiple security models. The fact that they live in the same specification is a editorial issue which is irrelevant to the discussion at hand. (In reply to comment #5) > sicking: what does the prefixing solve? Same thing as it always solves. It lets us use the unprefixed name but with different behavior if that's what we think is the better technical solution.
Also, prefixing signals to authors that it's a mozilla-only feature which we might deprecate at some point in the future.
We also want to do this in Opera.
Fair enough. I'll add this as a second argument to the constructor, whose value is a dictionary with (currently) one member, "withCredentials". Default will be false.
Checked in as WHATWG revision r6791. Check-in comment: Make EventSource support the Anonymous CORS mode. http://html5.org/tools/web-apps-tracker?from=6790&to=6791