Migrating exceptionMappings to SpringSecurity 2.0

[gcosgrave]

Hi,

I have been using Acegi's exceptionMappings on the AuthenticationProcessingFilter to redirect users to a Change Password page when a CredentialsExpiredException occurs

  <bean id="authenticationProcessingFilter" class="org.acegisecurity.ui.webapp.AuthenticationProcessingFilter">
    <property name="authenticationManager" ref="authenticationManager" />
    <property name="authenticationFailureUrl" value="/acegilogin.jsp?login_error=1" />
    <property name="exceptionMappings">
      <props>
        <prop key="org.acegisecurity.CredentialsExpiredException">/login/changePassword.htm</prop>
      </props>
    </property>
    <property name="defaultTargetUrl" value="/" />
    <property name="filterProcessesUrl" value="/j_acegi_security_check" />
  </bean>

How do do the equivalent with Spring Security 2?
below is my current configuration.

  <http access-decision-manager-ref="accessDecisionManager" xmlns="http://www.springframework.org/schema/security">
    <intercept-url pattern="/app/**" access="IS_AUTHENTICATED_FULLY" />
    <intercept-url pattern="/**" access="IS_AUTHENTICATED_ANONYMOUSLY" />
    <form-login login-page="/login.jsp" authentication-failure-url="/login.jsp?login_error=1"
      default-target-url="/"  />
    <http-basic />
    <anonymous />
    <logout />
  </http>

Thanks,
Gordon.

[hemalcshah]

You can achieve it by explicitly specifying authenticationFilter. Following blog might help:

http://hemalcshah.blogspot.com/2008/...in-spring.html

[Luke Taylor]

Don't forget that you can also use a BeanPostProcessor to tweak properties that the namespace doesn't support. This is probably acceptable for situations like this which are pretty straightforward. e.g.

public class ExceptionMappingsConfiguration implements BeanPostProcessor {
    Properties mappings; // inject this or hard code it as you wish
    
    Object postProcessBeforeInitialization(Object bean, String beanName) {
        if (bean instanceof AuthenticationProcessingFilter) {
            ((AuthenticationProcessingFilter)bean).setExceptionMappings(mappings);
        }
            
        return bean;
    }

    Object postProcessAfterInitialization(Object bean, String beanName) {
       return bean;
    }
}

[neila29]

I have hit the same issue several times now where the client has indicated they would rather use the namespace based configuration to do the full config. See thread 52556 and jira improvment requestSEC-778.

I have submitted some code to the jira issue that will allow the exceptions to be configured using the namespace. Luke do you think the code base can be updated to resolve the issue so that work around are not required?

Cheers
Neil

[Luke Taylor]

Well, as I've said before, the problem is that everyone wants their own specific issues catered for in the namespace . We definitely don't want to rush into adding things because removing them later is much harder. The intention isn't that the namespace should support all configuration options - you always have the option of using a traditional bean instead (or a post-processor, as I've described above).

Exception mappings may be something that we should look at but we intend to revisit the whole subject of redirection/forwarding within the framework for the next major version and it should be considered as part of that. For example, a strategy might be introduced to encapsulate the navigation behaviour when an exception occurs - similar to TargetUrlResolver (which will also probably be changed). This would be more flexible than the existing exception-mapping approach. So I agree that this kind of functionality would be useful within the namspace but it may not be right to implement it in the way you've suggested. The concept of an authentication failure isn't specific to form-based logins, so it may be that the strategy should be set within the <http> block itself and be applied to other authentication mechanisms.

[neila29]

Luke,

I agree that it may make more sense to create a common exception mapping bean that could be configured via the <http> block. This would allow other objects that could use custom mapping to be extended to make use of it, such as the switch user processor. (It would be a possible enhancement to allow the switch user processor to detect the exceptions thrown and redirect to a configured page.) Some care would need to be taken though to allow each bean to overwrite the exception mappings for any custom requirements. At present only the AuthenticationProcessingFilter extends the AbstractProcessingFilter and has the exception mappings. Hence the solution targeting the configuration of this bean within the <html> namespace config.

I do think that if a bean can be configured through the namespace all properties should be configurable. It does not make sense to me only allowing half of the bean to be configured. I am not sure what your thoughts are on this but that's my tupence worth

Which version is the next major version that you intend to have a look at this? 2.1? I have hit this issue several times and as such keen to correct this. Let me know if there is anything that I can do to help get this resolved. Time permitting I could modify my proposed solution to create an exception map from the root <html> namespace etc however I think it would be worthwhile having a conversation on the direction that you are thinking about taking this.

Regards
Neil