W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: [cors] Unrestricted access

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 14 Jul 2010 12:02:55 -0700
Message-ID: <AANLkTinSEd1QpFQyrTOUKGGOBGmrAtb3tJVjbK2dioaN@mail.gmail.com>
To: Tyler Close <tyler.close@gmail.com>
Cc: Anne van Kesteren <annevk@opera.com>, public-webapps@w3.org, Jaka Jančar <jaka@kubje.org>
On Wed, Jul 14, 2010 at 10:39 AM, Tyler Close <tyler.close@gmail.com> wrote:
> On Tue, Jul 13, 2010 at 8:12 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Tue, Jul 13, 2010 at 3:47 AM, Anne van Kesteren <annevk@opera.com> wrote:
>>> On Tue, 13 Jul 2010 12:35:02 +0200, Jaka Jančar <jaka@kubje.org> wrote:
>>>>
>>>> What I'd like is a global (per-host) way to disable these limitations all
>>>> at once, giving XHR unrestricted access to the host, just like native apps
>>>> have it.
>>>
>>> It used to be a mostly "global" per-resource switch, but the security folks
>>> at Mozilla thought that was too dangerous and we decided to go with the
>>> granular approach they proposed. This happened during a meeting in the
>>> summer of 2008 at Microsoft. I do not believe anything has changed meanwhile
>>> so this will probably not happen.
>>
>> This does not match my recollection of our requirements. The most
>> important requirements that we had was that it was possible to opt in
>> on a very granular basis, and that it was possible to opt in without
>> getting cookies. Also note that the latter wasn't possible before we
>> requested it and so this users requirements would not have been
>> fulfilled if it wasn't for the changes we requested.
>>
>> Anyhow if we want to reopen discussions about syntax for the various
>> headers that cors uses, for example to allow '*' as value, then I'm ok
>> with that. Though personally I'd prefer to just ship this thing as
>> it's a long time coming.
>
> Unless IE is soon to indicate support for all of the extra CORS
> headers, pre-flight requests and configuration caching, the decision
> should be to drop these unsupported features from the specification
> and come up with a solution that can achieve consensus among widely
> deployed browsers. I thought that was the declared policy for HTML5.
> As you know, I also think that is the right decision for many
> technical and security reasons.
>
> Jaka's request is reasonable and what the WG is offering in response
> is unreasonable. I expect many other web application developers will
> have needs similar to Jaka's. Meeting those needs with a simple
> solution is technically feasible. The politics seem to be much more
> difficult.

As far as I understand, UMP requires the exact same sever script, no?

/ Jonas
Received on Wednesday, 14 July 2010 19:09:01 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:39 GMT