cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: [proposal] Cross-Origin JAX-RS annotations
Date Fri, 02 Dec 2011 22:16:26 GMT
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.

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?

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?




>
> Agreed ? We just have one more annotation at the moment which is not secure
> enough, i.e, it;s not taken into account by the selection algorithm and thus
> it may go out of sync with the actual resource handlers, etc
>
> Sergey
>
> On 02/12/11 16:31, Benson Margulies wrote:
>>
>> the spec requires us to ignore the whole thing if it isn't a
>> space-separated list.
>>
>> On Dec 2, 2011, at 10:19 AM, Sergey Beryozkin<sberyozkin@gmail.com>
>>  wrote:
>>
>>> On 02/12/11 14:13, Benson Margulies wrote:
>>>>
>>>> On Fri, Dec 2, 2011 at 9:09 AM, Sergey Beryozkin<sberyozkin@gmail.com>
>>>> wrote:
>>>>>
>>>>> On 02/12/11 13:40, Benson Margulies wrote:
>>>>>>
>>>>>>
>>>>>> For the record, please see:
>>>>>>
>>>>>>
>>>>>> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1307.html
>>>>>>
>>>>>> Sergey, would it make any sense to add an injection annotation to
>>>>>> deliver the Origin header more conveniently (parsed on spaces into
a
>>>>>> list) or do you think that anyone who wants to make access control
>>>>>> decision should just use header injection?
>>>>>>
>>>>>> I've just checked in about 80% of all this.
>>>>>
>>>>>
>>>>>
>>>>> List<String>   values = HttpHeaders.getRequestHeader("Origin")
>>>>> should return the list of individual values, but I think it expects a
>>>>> ',' as
>>>>> a default separator;
>>>>> How about introducing a
>>>>> "org.apache.cxf.http.header.separator" property (def is ',') and update
>>>>> HttpHeadersImpl to use that property ?
>>>>
>>>>
>>>> The problem is that the Origin header is space-separated and the
>>>> others are comma-separated. So a property seems pretty scary to me.
>>>> Should the class just know that Origin is defined by W3C to be
>>>> space-separated?
>>>>
>>> Sounds good to me; I guess that even though it's space separated sosme
>>> clients will still use ',' - but we can handle that later; would you like me
>>> to fix that ?
>>> Sergey
>
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com

Mime
View raw message