FilterInvocationDefinitionSourceEditor does not allow empty attributes (RC2)

[Rolf Arne Corneliussen]

I upgraded from RC1 to RC2, and discovered that FilterInvocationDefinitionSourceEditor threw an IllegalArgumentException because I have several entries like

/css/**=

in my configuration.

I do this because I do not want to involve the Acegi machinery when serving style sheets and common images. In RC1 this worked great, but not so in RC2. What is the reason is was changed?

[Luke Taylor]

Sounds like this issue:

http://opensource2.atlassian.com/pro...browse/SEC-160

You could exclude the css directory at the FilterChainProxy instead, by adding an extra entry for it to the filterInvocationDefinitionSource property:

/css/**=someNullFilter
/images/**=someNullFilter
/**=httpSessionContextIntegrationFilter,etc.

which would probably be a more efficient way of excluding it from Acegi's handling.

[Rolf Arne Corneliussen]

This is exactly what I have done (I had to write a NullFilter class).

But Acegi supports null values for ConfigAttributeDefinitions in a FilterInvocationDefinitionMap, and it seems impossible in RC2 to set a explicit null value when configuring a FilterChainProxy (a null value is considered the 'marker' of a public object/invocation).

[Luke Taylor]

This is exactly what I have done (I had to write a NullFilter class).

It's a hard life

But Acegi supports null values for ConfigAttributeDefinitions in a FilterInvocationDefinitionMap, and it seems impossible in RC2 to set a explicit null value when configuring a FilterChainProxy (a null value is considered the 'marker' of a public object/invocation).

The getAttributes method from the ObjectDefinitionSource interface is defined as returning "null if no ConfigAttribiteDefinition applies" so I think it was probably coincidence that the syntax you were using had the effect of adding a null attribute to the definition. It would be preferrable to have something more explicit for labelling specific URLs as public, rather than using "/url=".
You could also use the AnonymousProcessingFilter to allow unprotected access to certain areas.

[Ben Alex]

As Luke noted, someNullFilter is not the recommended pattern and instead I'd encourage use of AnonymousProcessingFilter.

[Rolf Arne Corneliussen]

As Luke noted, someNullFilter is not the recommended pattern and instead I'd encourage use of AnonymousProcessingFilter.

Here is my configuration:

<bean id="filterChainProxy" class="org.acegisecurity.util.FilterChainProxy">
   <property name="filterInvocationDefinitionSource">
      <value>
         CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
         PATTERN_TYPE_APACHE_ANT
         /images/**=nullFilter
         /*.css=nullFilter
         /**=httpSessionContextIntegrationFilter,authenticationProcessingFilter,securityContextHolderAwareRequestFilter,exceptionTranslationFilter,filterInvocationInterceptor
      </value>
   </property>
</bean>

The nullFilter entries really functions as an 'exclusion' mechanism, for efficiency reasons, and the url's covered by the nullFilter are not listed in the configuration of the filterInvocationInterceptor (a FilterSecurityInterceptor)

What is the reason I should replace the nullFilter with the an anonymousProcessingFilter in this configuration? Are there any best practices not followed or any situation it is not safe with the nullFilter?

[Ben Alex]

You are right in that it is more efficient to do what you have done. It's just the non-standard approach, so support and new people to your project will take longer to get up to speed on the configuration.

[mkb]

Can anybody point me toward docs on how to do this with Acegi 0.9.0? I'm not in a position to upgrade and the instructions above didn't work for me.

Thanks,

--mkb