You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Sergey Beryozkin <sb...@gmail.com> on 2011/12/05 13:15:53 UTC
Some questions about the in CORS filter
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.
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
Re: Some questions about the in CORS filter
Posted by Sergey Beryozkin <sb...@gmail.com>.
>>>
>>> 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
Re: Some questions about the in CORS filter
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 05/12/11 15:39, Benson Margulies wrote:
> On Mon, Dec 5, 2011 at 10:15 AM, Sergey Beryozkin<sb...@gmail.com> wrote:
>> On 05/12/11 13:23, Benson Margulies wrote:
>>>
>>> On Mon, Dec 5, 2011 at 7:15 AM, Sergey Beryozkin<sb...@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).
>
> 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
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
Re: Some questions about the in CORS filter
Posted by Benson Margulies <bi...@gmail.com>.
On Mon, Dec 5, 2011 at 10:15 AM, Sergey Beryozkin <sb...@gmail.com> wrote:
> On 05/12/11 13:23, Benson Margulies wrote:
>>
>> On Mon, Dec 5, 2011 at 7:15 AM, Sergey Beryozkin<sb...@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).
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? 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.
>
> 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
>
>
Re: Some questions about the in CORS filter
Posted by Benson Margulies <bi...@gmail.com>.
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 <sb...@gmail.com> wrote:
> On 05/12/11 16:00, Benson Margulies wrote:
>>
>> On Mon, Dec 5, 2011 at 10:42 AM, Sergey Beryozkin<sb...@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<sb...@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
Re: Some questions about the in CORS filter
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Benson
On 05/12/11 16:11, Benson Margulies wrote:
> I translate Anne's answer just now as follows:
>
> To return information to the client, it has to be 2xx. So in the
> success case, it has to be 2xx. If it fails, we can do whatever we
> prefer: 2xx and no CORS headers or 4xx. I'm with you on a 4xx.
I've updated the filter to return an empty Response in case of preflight
failures but still keeping 200 by default, which can be customized to
410 or whatever status is preferred by a given client,
I thought that may be 410 was not that precise, as it does not indicate
to the client that the check actually took place. either way we can
configure the status :-)
Cheers, Sergey
Re: Some questions about the in CORS filter
Posted by Benson Margulies <bi...@gmail.com>.
I translate Anne's answer just now as follows:
To return information to the client, it has to be 2xx. So in the
success case, it has to be 2xx. If it fails, we can do whatever we
prefer: 2xx and no CORS headers or 4xx. I'm with you on a 4xx.
Re: Some questions about the in CORS filter
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 05/12/11 16:00, Benson Margulies wrote:
> On Mon, Dec 5, 2011 at 10:42 AM, Sergey Beryozkin<sb...@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<sb...@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
Re: Some questions about the in CORS filter
Posted by Benson Margulies <bi...@gmail.com>.
On Mon, Dec 5, 2011 at 10:42 AM, Sergey Beryozkin <sb...@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<sb...@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
Re: Some questions about the in CORS filter
Posted by Sergey Beryozkin <sb...@gmail.com>.
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<sb...@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 ?
>
>
>>
>> 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 :-)
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
Re: Some questions about the in CORS filter
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 05/12/11 13:23, Benson Margulies wrote:
> On Mon, Dec 5, 2011 at 7:15 AM, Sergey Beryozkin<sb...@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
Re: Some questions about the in CORS filter
Posted by Benson Margulies <bi...@gmail.com>.
On Mon, Dec 5, 2011 at 7:15 AM, Sergey Beryozkin <sb...@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.
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.
>
> 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