Re: [cors] JAX-RS and preflight

On Thu, Dec 1, 2011 at 6:53 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Thu, Dec 1, 2011 at 12:20 PM, Benson Margulies <bimargulies@gmail.com> wrote:
>> There's a problem with REST-ful services, as exemplified by the JAX-RS
>> standard, and CORS as drafted.
>>
>> A JAX-RS server names a resource, in part, via the content-type of a
>> request. A POST with content-type of application/json names a
>> different resource (in as much as it selects a different method to
>> call) that a POST with content-type text/plain.
>>
>> The problem here is that a preflight OPTIONS is defined to *not* pass
>> the content type unless it is simple. Thus, the service implementation
>> can't reliably tell what resource is under discussion.
>>
>> As things are, a service would have to take a common posture for all
>> preflights given the URL and Accept(-*) headers, and ignoring the
>> content type.
>>
>> Would you consider defining an Ac-Request-Content-Type header to pass
>> a non-simple content type on a preflight?
>
> You can always allow the OPTIONS request and make the security
> decision once you get the actual request.

Sure, if the server is the concerned party .... but ....

>
> The main point of the OPTIONS request is to protect servers that
> aren't aware of CORS at all. Clearly a CORS+JAX-RS doesn't fall into
> this category.

As a superannuated security person, I thought that the point of CORS
was to protect clients from cross-scripting pranks of web pages, not
to protect servers from anything. Nothing in CORS involves returning a
401. Wouldn't the actual access decision be made on the server instead
of on the client if we were protecting the server? Why return all this
stuff to the client instead of failing requests or censoring headers?

Something tells me that there's a theory here that I haven't read yet.


>
> / Jonas

Received on Friday, 2 December 2011 00:14:50 UTC