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 15:59:53 GMT
>>>
>>> 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).
>>
>> Yes, I see the problem here, but I don't quite know what to do.
>>
>> Preflight seems to be carefully defined to get along with any existing
>> OPTIONS handling that is going on. So, if the programmer has an
>> OPTIONS method that matches, the situation is supposed to be the same
>> as the situation with simple requests and, say, GET handlers.
>>
>> Will the JAX-RS code ever dispatch OPTIONS to a function that doesn't
>> have an @OPTIONS?
> No
>> If so, I think that the problem here is more
>> serious. If not, I'm not sure we have a problem. I'm also not sure
>> that the CORS spec exactly makes sense, and I'm going to send them
>> some email.
>>
> My understanding now is that the client decides on whether a preflight
> failed or not by checking the response headers.
> Our in filter adds them one by one, or rather it prepares the info for
> the out filter to decide what to add in case of preflights being processed.
> Thus if the client always expects OK and only uses headers to figure out
> what happened then the in filter should just always return Response.OK,
> the earlier it does so the less info it will save for the response
> filter and the less chance the response filter will have to provide all
> the expected headers - but some clarifications at the spec level will help

So it is 410 - I'll do a quick update and ask for the review
Sergey

>
> Cheers, Sergey
>
>>
>>>
>>> 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.
>>>>
>>>
>>> [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