cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: Some questions about the in CORS filter
Date Mon, 05 Dec 2011 16:04:40 GMT
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