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:15:21 GMT
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).

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


Mime
View raw message