On Mon, Dec 5, 2011 at 10:42 AM, Sergey Beryozkin <sberyoz...@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<sberyoz...@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
