cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: Some questions about the in CORS filter
Date Mon, 05 Dec 2011 16:09:37 GMT
At some point, we're going to need to try some experiments with a
browser and make sure that whatever it is we've done actually works.
Unfortunately, htmlunit doesn't have this client side yet (I'm working
on a patch). I suppose I should read the source of Chromium or
something, unless you beat me to it.

On Mon, Dec 5, 2011 at 11:04 AM, Sergey Beryozkin <sberyozkin@gmail.com> wrote:
> On 05/12/11 16:00, Benson Margulies wrote:
>>
>> On Mon, Dec 5, 2011 at 10:42 AM, Sergey Beryozkin<sberyozkin@gmail.com>
>>  wrote:
>>>
>>> Hi
>>>
>>> On 05/12/11 15:15, Sergey Beryozkin wrote:
>>>>
>>>>
>>>> On 05/12/11 13:23, Benson Margulies wrote:
>>>>>
>>>>>
>>>>> On Mon, Dec 5, 2011 at 7:15 AM, Sergey Beryozkin<sberyozkin@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Hi Benson, all
>>>>>>
>>>>>> At the moment the in CORS filter returns 'null' during a preflight
>>>>>> check,
>>>>>> whenever some check fails, which means that most likely an HTTP
>>>>>> status code
>>>>>> will be returned to do with failure at the selection algorithm stage,
>>>>>> but
>>>>>> that status code may not necessarily to be the one expected by the
>>>>>> CORS
>>>>>> client ? I'm wondering of we should return some more specific HTTP
>>>>>> status
>>>>>> code instead of depending on the runtime to eventually fail this
>>>>>> preflight
>>>>>> request.
>>>>>
>>>>>
>>>>>
>>>>> Maybe I don't understand filters.
>>>>>
>>>>> The cors spec never, ever, calls for failing the overall HTTP request.
>>>>> It calls for adding extra headers if the request is good, and not
>>>>> adding them if it is bad, and otherwise leaving it alone.
>>>>
>>>>
>>>> Are you referring to the actual request which follows a preflight
>>>> request
>>>> ?
>>>>
>>>> I'm looking at [1] and I'm not sure how does the client (browser ?) can
>>>> decide that a preflight request was not successful.
>>>>
>>>> The filter returns Response.ok().build() in the end of the preflight
>>>> check, which indeed will let the out CORS filter to finalize the
>>>> preflight response but in cases where the preflight check was not good
>>>> then I believe a random HTTP error status will be returned depending on
>>>> where the selection algorithm fails afterwards (may be it is a path
>>>> mismatch or unexpected verb/content-type/accept-type).
>>>>
>>> I can see the out filter sets certain values
>>> in case of a preflight response - but it can only guess that the
>>> preflight
>>> took place only if the in filter managed to reach the end of its
>>> preflight
>>> processing.
>>>
>>> I guess we need to set a message with a "preflight" and return
>>> Response.ok().build() in all the branches in the in preflight handler,
>>> right ?
>>
>>
>>
>> That's exactly what I'm trying to sort out with the w3c mailing list.
>> There are two cases:
>>
>> 1) There's an @OPTIONS method that applies. In this case, it seems
>> pretty clear to me that the appropriate response is whatever comes
>> from the @OPTIONS method.
>>
> +1
>
>
>> 2) There's no @OPTIONS method. In this case, I'm leaning to returning
>> an OK whether the preflight algorithm succeeds or fails, on the
>> grounds that the server successfully handled the OPTIONS -- and the
>> returned headers are the information the client was looking for.
>>
> I think it is still 410 - it does not matter to the client side why it is
> 410 (network/domain error or a custom preflight check error), either way
> it's a failure, but I'll pause a bit :-)
>
> Cheers, SErgey
>
>
>>
>>>
>>>>
>>>>
>>>>>
>>>>> Now, we could design a unified JAX-RS security feature that
>>>>> incorporated CORS as part of its job. It could, if asked, fail
>>>>> requests if they failed to meet the requirements.
>>>>>
>>>
>>> By the way, I start thinking we should move this code to its own
>>> rs/security/cors because it is really about the security and something
>>> tells
>>> me some more code will come :-)
>>
>>
>> no argument.
>>
>>>
>>> Cheers, Sergey
>>>
>>>
>>>>
>>>> [1] http://www.w3.org/TR/cors/
>>>>
>>>>>>
>>>>>> The other question which we've discussed with Benson is what to do
in
>>>>>> the
>>>>>> case like this:
>>>>>>
>>>>>> @Path("/somepath")
>>>>>> public class Resource {
>>>>>> @GET
>>>>>> @Produces("application/xml")
>>>>>> public Book getXML() {}
>>>>>>
>>>>>> @GET
>>>>>> @Produces("application/json")
>>>>>> public Book getXML() {}
>>>>>> }
>>>>>>
>>>>>> The info CORS provides is sufficient enough to select either of the
>>>>>> the
>>>>>> above 2 methods thus the question is what to do at the preflight
>>>>>> check.
>>>>>> In this case we thought we can expect a
>>>>>> CrossResourceSharingAnnotation being
>>>>>> added to the 'good' method, or even to the all of them, possibly
uing
>>>>>> a
>>>>>> class-level annotation:
>>>>>>
>>>>>> @Path("/somepath")
>>>>>> @CrossResourceSharingAnnotation(...)
>>>>>> public class Resource {
>>>>>> @GET
>>>>>> @Produces("application/xml")
>>>>>> public Book getXML() {}
>>>>>>
>>>>>> @GET
>>>>>> @Produces("application/json")
>>>>>> public Book getXML() {}
>>>>>> }
>>>>>>
>>>>>> or in case of POST:
>>>>>>
>>>>>> @Path("/somepath")
>>>>>> public class Resource {
>>>>>> @POST
>>>>>> @Consumes("application/xml")
>>>>>> @CrossResourceSharingAnnotation(...)
>>>>>> public void addXML(Book) {}
>>>>>>
>>>>>> @POST
>>>>>> @Consumes("multipart/form-data")
>>>>>> public void upload(MultipartBody) {}
>>>>>> }
>>>>>>
>>>>>> We can also think of some configuration tricks.
>>>>>> Ex, if the consumer does know that only an upload POST method is
>>>>>> 'valid'
>>>>>> then we can configure a CORS filter with the acceptType value which
>>>>>> will be
>>>>>> passed on to the JAXRS runtime to confirm that such a method actually
>>>>>> exists
>>>>>>
>>>>>> For the record, as agreed with Benson, I updated the filter to
>>>>>> delegate to
>>>>>> the runtime to find a valid matching method during a preflight check
>>>>>> which
>>>>>> is more secure than depending on the custom annotation
>>>>>>
>>>>>> Cheers, Sergey
>>>>>>
>>>>>> --
>>>>>> Sergey Beryozkin
>>>>>>
>>>>>> Talend Community Coders
>>>>>> http://coders.talend.com/
>>>>>>
>>>>>> Blog: http://sberyozkin.blogspot.com
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Sergey Beryozkin
>>>
>>> Talend Community Coders
>>> http://coders.talend.com/
>>>
>>> Blog: http://sberyozkin.blogspot.com

Mime
View raw message