Hi Benson
On 02/12/11 22:16, Benson Margulies wrote:
On Fri, Dec 2, 2011 at 4:45 PM, Sergey Beryozkin<sberyoz...@gmail.com> wrote:
Hi Benson
I think we should get rid of that Class level annotation that you
introduced. It is not secure enough - the path and verb values it lists -
they can not serve as a guarantee that the actual resource handler exists.
They simply duplicate @Path& @GET/friends.
I propose to get rid of it.
As I said, JAXRSUtils.getResourceClass& JAXRSUtils.findOperation are the
only guarantee and we should not be concerned if we have multiple GET
handlers listening on the same path but differing in @Produces.
Sergey,
I don't yet agree(, but you'll probably convince me eventually). The
whole thrust of my discussion with the CORS people is that CORS isn't
exactly security. A service cannot delegate security to the browser.
The browser could be hacked.
The effect of CORS is to instruct the browser to open up a range of
resources, but it's still up to the actual handlers for those
resources in the server to implement security.
@CrossScriptResourceSharing can be used to enforce the security on the
server side; the class-level annotation may give us the illusion of
security at the CORS level but it won't guarantee that JAXRS runtime
will actually find such a matching resource.
The only vocabulary for instructing the browser is URI+method, and the
annotation does that.
That being said, could I interest you in starting by producing an
alternative version of the package.html that would explain to a user
how to use your preferred alternative?
I'll try but a bit later on once I get to grips with CORS :-)
If I could read a user-facing document that explained what a user
should do, I'd stop carping.
Meanwhile, I had a thought that may just be identical to yours, but
I'm feeling really slow.
Let's say that we eliminate the nested annotation business. Also note
that this mess only applies to preflight, so as an example I'll talk
about PUT.
Now, what exactly happens if we have multiple @PUT handlers for the
same URI that dispatch on the incoming Content-Type, or on the
presence of particular multipart pieces, which are the losing cases?
We could say: Only one of them may have a @CrossScriptResourceSharing
annotation. If more than one have it, we throw. Or we log and decline
fail the CORS transaction.
How's about that?
Exactly, +1. We don't need to worry right now about such fine-grained
cases where we have multiple PUT handlers which only differ from each
other by accepted or produced media types, if CORS will eventually get
other headers introduced to do with the major headers such as
Content-Type or Accept then we will deal with such cases better.
So the method selected by the runtime must contain the annotation
@CrossScriptResourceSharing.
I think we should configure the CORS filter with preferred Content-Type
& Accept header values which if set will be used during the try
selection initiated by the CORS filter, otherwise we can just default to
*/*; it will only be needed when the developer know that say multiple
PUT handlers exist;
So JAXRSUtils.findResourceClass followed by JAXRSUtils.findTargetMethod
in combination with @CrossScriptResourceSharing is all we need;
Cheers, Sergey
