cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: CORS: removing allowOrigins from the annotation only
Date Wed, 14 Mar 2012 11:19:49 GMT
Hi Aki
On 14/03/12 11:12, Aki Yoshida wrote:
> Hi Sergey,
> I am not familiar with this stuff, so what I am saying may not make
> sense, though :-)
>
thanks for the comments, they make sense :-)
> But can you use the different default value so that you can
> distinguish between the null (i.e., interpreted as
> allowAllOrigins=true) and an empty allowOrigins  (i.e.,
> allowAllOrigins=false) ?
>

I was just about to press commit when I saw your message :-).
For the moment I restored that flag, as opposed to deleting the 
allowOrigins completely, one the basis that all other 
CrossOriginResourceSharing properties can equally be considered not 
method specific, but the endpoint specific...
I briefly thought earlier on about the 'marker' value for allowOrigins, 
but the allowOrigins is an array, so having some marker value would 
probably complicate a bit the processing as one would need to also 
consider the case where valid and a marker properties are mixed in...

Thanks, Sergey

> regards, aki
>
> 2012/3/14 Sergey Beryozkin<sberyozkin@gmail.com>:
>> Hi Benson, all,
>>
>> I've been modifying the CrossOriginResourceSharing annotation as well as the
>> CrossOriginResourceSharingFilter during the last couple of days to address
>> the issue reported by Matt Bishop, namely, to do with making it possible to
>> avoid specifying "allowOrigins" within the CrossOriginResourceSharing
>> annotation, given that "allowOrigins" keeps the list of absolute URIs thus
>> it is not ideal at all to have it declared in the actual code.
>>
>> CrossOriginResourceSharing used to have an 'allowAllOrigins' boolean
>> property set by default to 'false' and also the 'allowOrigins' list/array
>> property, the latter was ignored if 'allowAllOrigins' was set to true.
>>
>> Additionally, similar properties exist in CrossOriginResourceSharingFilter
>> which can be effective when the annotation is not set on a given method.
>>
>> I started with removing what I thought was a redundant
>> CrossOriginResourceSharing 'allowAllOrigins', instead assuming that an
>> empty/default 'allowOrigins' does mean 'allow all origins'.
>>
>> The problem I'm seeing with this now that in order to be possible to avoid
>> specifying specific 'allowOrigins' in the application code within
>> CrossOriginResourceSharing one has to choose not to use
>> CrossOriginResourceSharing because if it is provided it takes the preference
>> over the possible custom values set in the filter.
>>
>> So one option is to restore the boolean "allowAllOrigins" flag. By default
>> it is set to 'false'. Thus if CrossOriginResourceSharing' allowOrigins is
>> empty then there must be a filter property set customizing the allowOrigins
>> to meet the allowAllOrigins==false requirement.
>>
>> Another option is to remove CrossOriginResourceSharing' allowOrigins and
>> expect the filter customize it when needed.
>> The idea here is that it appears to be unlikely various individual methods
>> within a current JAX-RS endpoint may have different allowed origins, rather
>> it's more likely that the allowOrigins are going to be shared by all the
>> JAX-RS methods for a given endpoint.
>>
>> So I kind of prefer the 2nd option but at the same time I'm OK with
>> restoring the flag for the sake of simplifying the testing and such at a
>> minor cost of keeping the somewhat redundant 'allowAllOrigins'...
>>
>> Let me know please what you think
>>
>> Cheers, Sergey
>>
>>
>>
>>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

Mime
View raw message