Announcement Announcement Module
Collapse
No announcement yet.
FilterInvocationDefinitionSourceEditor does not allow empty attributes (RC2) Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • FilterInvocationDefinitionSourceEditor does not allow empty attributes (RC2)

    I upgraded from RC1 to RC2, and discovered that FilterInvocationDefinitionSourceEditor threw an IllegalArgumentException because I have several entries like
    Code:
    /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?

  • #2
    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.

    Comment


    • #3
      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).

      Comment


      • #4
        Originally posted by Rolf Arne Corneliussen
        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.

        Comment


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

          Comment


          • #6
            Originally posted by Ben Alex
            As Luke noted, someNullFilter is not the recommended pattern and instead I'd encourage use of AnonymousProcessingFilter.
            Here is my configuration:

            Code:
            <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?

            Comment


            • #7
              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.

              Comment


              • #8
                What about 0.9.0?

                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

                Comment

                Working...
                X