At some point, we're going to need to try some experiments with a browser and make sure that whatever it is we've done actually works. Unfortunately, htmlunit doesn't have this client side yet (I'm working on a patch). I suppose I should read the source of Chromium or something, unless you beat me to it.
On Mon, Dec 5, 2011 at 11:04 AM, Sergey Beryozkin <sberyoz...@gmail.com> wrote: > On 05/12/11 16:00, Benson Margulies wrote: >> >> 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. >> > +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
