W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: [cors] JAX-RS and preflight

From: Benson Margulies <bimargulies@gmail.com>
Date: Fri, 2 Dec 2011 08:29:24 -0500
Message-ID: <CALhtWkeQGdX1SCA3EOkzumcgaRc3xJnyopSNTmce6KHwpMp4VQ@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: public-webapps@w3.org, Sergey Beryozkin <sberyozkin@gmail.com>

Let me circle back to the top now and see if I can play this back.

1. Of course, when writing a server, it's up to me to implement access
control decisions.

2. To protect a plethora of poorly-protected servers out there, CORS
puts an additional level of access control in clients.

3. To expose resources cross-origin, my service has to reassure the
client that it does, indeed, know what it is doing. That  reassurance
is delivers via the CORS headers.

4. There's a impedance mismatch between the CORS model of resource
control, which is URI+method, and the JAX-RS model, which adds other

5. A server thus must return CORS indications at the level  of
URI+method. This 'opens the door' in the client -- and then the server
is responsible for imposing any fine-grained access control that it
wants at the level of the other headers.


On Thu, Dec 1, 2011 at 8:07 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Thu, Dec 1, 2011 at 4:35 PM, Benson Margulies <bimargulies@gmail.com> wrote:
>> Here's where I am not following:
>> If I am trying to protect a server, I will look at the request, and if
>> I don't like it, I will return a 401. Period. I'm happy to have the
>> Origin header to help me do that. I don't see what the rest of the
>> complex processing does for me.
> As someone aware of CORS the rest of the processing doesn't really do
> anything for you.
> However, imagine that you set up your server 5 years ago. Or that you
> weren't aware of the existence of CORS. Then you obviously wouldn't be
> looking at the Origin header. Or return a 401. You would just gladly
> server whatever request that was posed to you.
> This is why CORS has additional checks in the client. To ensure that
> servers that aren't aware of CORS don't return any sensitive
> information to the requesting page, or that the requesting page can't
> case sensitive side effects on the server.
>> In particular, would I delegate the work to the CORS client? How do I
>> know that the client really implements the spec?  Consider
>> 'Expose-Headers' ... If I don't want them to go to a particular
>> origin, why would I bother to return all this metadata in a preflight
>> instead of, well, just not returning them? Am I just trying to make it
>> easier for client-side processes to understand my rules?
> The idea is to give you plenty of tools to make it easy to protect yourself.
> If you have lots of code running on your server and you are not fully
> sure what all of it does, but you still want to expose some specific
> header to the requesting page, you simply whitelist that header. That
> way you don't have to worry about making the rest of your code
> foolproof.
> So while you can provide belts, we'll still provide suspenders :-)
> / Jonas
Received on Friday, 2 December 2011 13:29:59 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:37 UTC