cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject CORS: removing allowOrigins from the annotation only
Date Tue, 13 Mar 2012 23:58:08 GMT
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

View raw message