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
