Spring Security
  1. Spring Security
  2. SEC-778

exceptionMappings configuration in default namespace

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.0.0
    • Fix Version/s: 3.0.0 M1
    • Component/s: Core
    • Labels:
      None

      Description

      Would it be possible to update the namespace based configuration to allow exception mappings to be created for the default authentication processing filter created via the form-login. This would be useful when cutting down the XML required to configure spring security.

      Regards
      Neil

        Issue Links

          Activity

          Hide
          Luke Taylor added a comment -

          To be reviewed for 2.1

          Show
          Luke Taylor added a comment - To be reviewed for 2.1
          Hide
          Neil Anderson added a comment -

          I hit this issue again and was wondering if there is something that can be done in the short term. Not being able to set exceptionMappings on the AuthenticationProcessingFilter via the namespace based configuration is a pain. The result is verbose XML has to be produced to do the mapping.

          An update that would resolve the problem would be to allow something like the following XML by updating the security schema. The FormLoginBeanDefinitionParser could then be updated to produce the exceptionMappings list.

          <security:form-login login-page="/login.html"
          login-processing-url="/security_check"
          authentication-failure-url="/login.html"
          default-target-url="/index.html">
          <security:exception-mapping exception="org.springframework.security.DisabledException" target-url="/accountDisabled.html" />
          <security:exception-mapping exception="org.springframework.security.AccountExpiredException" target-url="/accountExpired.html" />
          </security:form-login>

          Regards
          Neil

          Show
          Neil Anderson added a comment - I hit this issue again and was wondering if there is something that can be done in the short term. Not being able to set exceptionMappings on the AuthenticationProcessingFilter via the namespace based configuration is a pain. The result is verbose XML has to be produced to do the mapping. An update that would resolve the problem would be to allow something like the following XML by updating the security schema. The FormLoginBeanDefinitionParser could then be updated to produce the exceptionMappings list. <security:form-login login-page="/login.html" login-processing-url="/security_check" authentication-failure-url="/login.html" default-target-url="/index.html"> <security:exception-mapping exception="org.springframework.security.DisabledException" target-url="/accountDisabled.html" /> <security:exception-mapping exception="org.springframework.security.AccountExpiredException" target-url="/accountExpired.html" /> </security:form-login> Regards Neil
          Hide
          Neil Anderson added a comment -

          The attachment contains a proposed solution to the issue where you can not configure the 'exceptionMappings' on the AuthenticationProcessingFilter class via the namespace based configuration. The change does not effect any existing namespace configuration and is backwards compatible. The update will allow the following configuration within the http security element:

          <security:form-login login-page="/login.html"
          login-processing-url="/security_check"
          authentication-failure-url="/login.html"
          default-target-url="/home.html">
          <security:exception-mapping exception="org.springframework.security.DisabledException" target-url="/accountDisabled.html" />
          <security:exception-mapping exception="org.springframework.security.AccountExpiredException" target-url="/accountExpired.html" />
          <security:exception-mapping exception="org.springframework.security.LockedException" target-url="/accountLocked.html" />
          <security:exception-mapping exception="org.springframework.security.CredentialsExpiredException" target-url="/credentialsExpired.html" />
          </security:form-login>

          The update is based on the current 2.0.4 snapshot from svn and is valid as of the 24th of July 2008.

          I would appreciate it if you would take a look at this and check the code in for the 2.0.4 release if you are happy with the code.

          Regards
          Neil Anderson

          Show
          Neil Anderson added a comment - The attachment contains a proposed solution to the issue where you can not configure the 'exceptionMappings' on the AuthenticationProcessingFilter class via the namespace based configuration. The change does not effect any existing namespace configuration and is backwards compatible. The update will allow the following configuration within the http security element: <security:form-login login-page="/login.html" login-processing-url="/security_check" authentication-failure-url="/login.html" default-target-url="/home.html"> <security:exception-mapping exception="org.springframework.security.DisabledException" target-url="/accountDisabled.html" /> <security:exception-mapping exception="org.springframework.security.AccountExpiredException" target-url="/accountExpired.html" /> <security:exception-mapping exception="org.springframework.security.LockedException" target-url="/accountLocked.html" /> <security:exception-mapping exception="org.springframework.security.CredentialsExpiredException" target-url="/credentialsExpired.html" /> </security:form-login> The update is based on the current 2.0.4 snapshot from svn and is valid as of the 24th of July 2008. I would appreciate it if you would take a look at this and check the code in for the 2.0.4 release if you are happy with the code. Regards Neil Anderson
          Hide
          Luke Taylor added a comment -

          This thread is also related to this issue:

          http://forum.springframework.org/showthread.php?t=54723

          My comment from there explains why we don't want define exception mappings explicitly for form-login:

          "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."

          This concept also applies to other filters such as OpenID and will be considered as part of our overall strategy for handling destination URLs.

          Show
          Luke Taylor added a comment - This thread is also related to this issue: http://forum.springframework.org/showthread.php?t=54723 My comment from there explains why we don't want define exception mappings explicitly for form-login: "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." This concept also applies to other filters such as OpenID and will be considered as part of our overall strategy for handling destination URLs.
          Hide
          Luke Taylor added a comment -

          Making SEC-745 the parent issue URL-navigation behaviour.

          Show
          Luke Taylor added a comment - Making SEC-745 the parent issue URL-navigation behaviour.
          Hide
          Luke Taylor added a comment -

          Superseded by SEC-745 (and subtasks).

          Show
          Luke Taylor added a comment - Superseded by SEC-745 (and subtasks).

            People

            • Assignee:
              Luke Taylor
              Reporter:
              Neil Anderson
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: