SEC-1256: Cannot use bean configuration to configure a FilterSecurityMetadataSource with SpEL expressions due to hard-coded "false" value in code #1492

Closed
spring-issuemaster opened this Issue Oct 5, 2009 · 2 comments

1 participant

@spring-issuemaster

Peter Mularien (Migrated from SEC-1256) said:

I ran into this as I was trying to configure a Spring Sec stack without the security namespace in place. In 3.0.0M2 there is a hard-coded "false" for useExpressions in the FilterInvocationSecurityMetadataSourceBeanDefinitionParser, at the following line (on or about line 47):

    LinkedHashMap<RequestKey, List<ConfigAttribute>> requestMap =
    HttpSecurityBeanDefinitionParser.parseInterceptUrlsForFilterInvocationRequestMap(interceptUrls,
            convertPathsToLowerCase, false, parserContext);

I believe this code should be augmented to look for the "use-expressions" attribute on the sec:filter-security-metadata-source element. The resultant code would look something like the following (note, I haven't been able to get a compilable version of Spring Sec from source, otherwise I'd supply a patch :) ):

    boolean useExpressions = false;
    if(StringUtils.hasLength(element.getAttribute(HttpSecurityBeanDefinitionParser.ATT_USE_EXPRESSIONS))) {
        useExpressions = Boolean.parseBoolean(element.getAttribute(HttpSecurityBeanDefinitionParser.ATT_USE_EXPRESSIONS));
    }
    LinkedHashMap<RequestKey, List<ConfigAttribute>> requestMap =
    HttpSecurityBeanDefinitionParser.parseInterceptUrlsForFilterInvocationRequestMap(interceptUrls,
            convertPathsToLowerCase, useExpressions, parserContext);

Note also that in order to use this code patch you'll have to expand the visibility of the constant reference ATT_USE_EXPRESSIONS.

Since I can't verify that SpEL access declarations work with this fix (although they should), I can't guarantee this is all-inclusive, but hopefully it'll be close!

Sample bean definition (although you probably don't need it):

<bean id="filterSecurityInterceptor" class="org.springframework.security.web.access.intercept.FilterSecurityInterceptor">
  <property name="authenticationManager" ref="customAuthenticationManager"/>
  <property name="accessDecisionManager" ref="affirmativeBased"/>
  <property name="securityMetadataSource">
    <security:filter-security-metadata-source use-expressions="true">
        <security:intercept-url pattern="/login.do" access="permitAll"/>
        <security:intercept-url pattern="/home.do" access="permitAll"/>
        <security:intercept-url pattern="/account/*.do" access="hasRole('ROLE_USER') and fullyAuthenticated"/>
        <security:intercept-url pattern="/*" access="hasRole('ROLE_USER')"/>
    </security:filter-security-metadata-source>
  </property>
</bean>

You needn't worry about analyzing the expressions for correctness - I've verified they work already using the standard format. Thanks for reviewing the bug!

@spring-issuemaster

Luke Taylor said:

Thanks for the report, Peter.

The build should always be working fine (check http://build.springsource.org/browse/SEC-TRUNK). If you have a problem compiling then please report it separately, giving details of the error.

@spring-issuemaster

Luke Taylor said:

Should be fixed. Also requires that the correct FilterSecurityMetadataSource bean class be selected, depending on whether expressions are enabled or not.

@spring-issuemaster spring-issuemaster added this to the 3.0.0 RC1 milestone Feb 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment