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:00:32 GMT
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.

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.


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