Re: [cors] Unrestricted access

On Wed, Jul 14, 2010 at 12:02 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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?

UMP Level One doesn't use pre-flight requests so doesn't have this
complexity, but also doesn't enable arbitrary HTTP methods and
headers. Instead, the plan was to have UMP Level Two introduce a
well-known URL per host that could be consulted to turn on this
functionality for all resources. Level One and Level Two are split
since Level One is meant to cover only things that are currently
deployed.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Received on Thursday, 15 July 2010 00:26:18 UTC