Hi Sergey, I am not familiar with this stuff, so what I am saying may not make sense, though :-)
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) ? regards, aki 2012/3/14 Sergey Beryozkin <[email protected]>: > 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 > > > >
