Re: [cors] JAX-RS and preflight

Jonas,

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
headers.

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.

--benson


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