Announcement Announcement Module
Collapse
No announcement yet.
Why do I need to declare <login-form...> twice? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Why do I need to declare <login-form...> twice?

    We've got a spring security setup that looks (in part) like this:

    Code:
        <!-- Auth Code authorization page -->
        <http pattern="/oauth/authorize" disable-url-rewriting="true" >
            <intercept-url pattern="/oauth/authorize" access="ROLE_USER"/>
            <form-login
                    login-page="/login"
                    default-target-url="/oauth/authorize"
                    authentication-success-handler-ref="authCodeAuthenticationSuccessHandler"
                    authentication-failure-handler-ref="authCodeAuthenticationFailureHandler"
            />
            <logout logout-success-url="/logout" logout-url="/logout.do"/>
            <custom-filter ref="authCodeEventFilterForMetricsLogging" position="FIRST"/>
        </http>
    
        <http pattern="/log(in|out).*|/spring_security_log(in|out).*|/j_spring_security_check.*|/resources/.*"
              request-matcher="regex"
              disable-url-rewriting="true"
              xmlns="http://www.springframework.org/schema/security">
            <form-login
                    login-page="/login"
                    default-target-url="/oauth/authorize"
                    authentication-success-handler-ref="authCodeAuthenticationSuccessHandler"
                    authentication-failure-handler-ref="authCodeAuthenticationFailureHandler"
            />
            <logout logout-success-url="/logout" logout-url="/logout.do"/>
        </http>
    Note that we are forced to declare the <form-login ...> configuration twice. The app will not work properly without duplicate form-login entries.

    The first instance, above, I understand. It makes sense that for "protected" resources (our AuthCode authorization page), Spring needs to know how to get unauthenticated users authenticated.

    The 2nd instance, above, I don't get. We declare that the login, logout, etc. pages don't need auth. That makes complete sense. But why, then do we need to *again* declare the form-login configuration here? This is really confusing.

    Can somebody shed some light on this?

    Thanks!

    Gary

  • #2
    Different <http> blocks define separate filter chains. The point is that you can use different <form-login> configurations for each chain, for example. That's exactly what it's intended for. If one configuration arbitrarily pulled in bits of another (which seems to be what you are suggesting here), that would be extremely confusing.

    It's not clear why you need separate filter chains for this configuration at all. Perhaps you should explain what you are trying to achieve?

    Comment


    • #3
      Originally posted by Luke Taylor View Post
      Different <http> blocks define separate filter chains. The point is that you can use different <form-login> configurations for each chain, for example. That's exactly what it's intended for. If one configuration arbitrarily pulled in bits of another (which seems to be what you are suggesting here), that would be extremely confusing.

      It's not clear why you need separate filter chains for this configuration at all. Perhaps you should explain what you are trying to achieve?
      Thanks for reply. Two things:

      In my posted example, the two filter chains do not act independently (they *should* act independently, I agree, but they don't). <form-login> definitions in one chain affect the <form-login> definitions in another. In order for the configuration to work, we have to ensure that *both* form-login definitions are exactly the same. Differences in the definitions do not yield predictable behavior (it appears that the 2nd definition overwrites the 1st).

      The reason we are defining two filter chains is that the authentication for the two URL-patterns is very different.

      The "/oauth/authorize" pattern should have form-based login applied.

      The "/log(in|out).*|/spring_security_log(in|out).*|/j_spring_security_check.*|/resources/.*" pattern should have *no* authentication applied since these are patterns into Spring's login/logout pages (as well as a directory containing our unprotected "resources"). The <form-login> definition for this chain makes no sense here but the app fails to configure properly without its presence.

      Any guidance?

      Thank you!

      Gary

      Comment

      Working...
      X