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 ?
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
