cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: [proposal] Cross-Origin JAX-RS annotations
Date Fri, 02 Dec 2011 22:38:52 GMT
Hi Benson

On 02/12/11 22:16, Benson Margulies wrote:
> On Fri, Dec 2, 2011 at 4:45 PM, Sergey Beryozkin<sberyozkin@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

Mime
View raw message