Announcement Announcement Module
Collapse
No announcement yet.
Spring Security 3.1.0.M2 and SavedRequestAwareAuthenticationSuccessHandler Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring Security 3.1.0.M2 and SavedRequestAwareAuthenticationSuccessHandler

    Hello Guys,

    In the process of setting up to filter chains to handle both form based and API based authentication I have come across an issue related he proper redirecting after successful authentication.

    couple of things.

    1. When using SavedRequestAwareAuthenticationSuccessHandler it seems to me that the request is actually saved in the ExceptionTranslationFilter however this is called after the my AuthenticationFilter filter which uses a SavedRequestAwareAuthenticationSuccessHandler one successful authenticaion. According to the reading I have done the order I have defined the filters is correct


    <sec:filter-chain pattern="/dyn/api/**" filters="securityContextFilterWithASCFalse,
    apikeyAuthFilter,
    servletApiFilter,
    exceptionTranslationFilterForRestServices,
    filterSecurityInterceptor"/>


    Secondly the redirect URL seems to be incorrect in any case since the FirewalledRequestWrapper is stripping most of the path related information?

    I will keep diving deeper but if anyone has any initial thoughts that would be helpful?

    Thanks,
    Serge

  • #2
    That's correct. ExceptionTranslationFilter stores the request, you authenticate and the AuthenticationSuccessHandler retrieves the saved request and redirects to that URL.

    The RequestCacheFilter restores the request on the subsequent invocation.

    You'll need to expand on what you mean about the path information being stripped? What is the original URL you want to redirect to and what information is being lost? Are you using path parameters in the URL?

    Comment


    • #3
      Hello Luck,

      Thanks for the quick response.

      Originally posted by Luke Taylor View Post
      That's correct. ExceptionTranslationFilter stores the request, you authenticate and the AuthenticationSuccessHandle
      Sorry if I am being daft here but if the AuthenticationSuccessHandler is executed before passing through the ExceptionTranslationFilter, how does this work?


      Originally posted by Luke Taylor View Post
      You'll need to expand on what you mean about the path information being stripped? What is the original URL you want to redirect to and what information is being lost? Are you using path parameters in the URL?
      Never mind, I am being stupid...

      Thanks,
      Serge
      Last edited by ssozonoff; Jan 26th, 2011, 04:22 PM.

      Comment


      • #4
        Originally posted by ssozonoff View Post

        Sorry if I am being daft here but if the AuthenticationSuccessHandler is executed before passing through the ExceptionTranslationFilter, how does this work?
        The AuthenticationSuccessHandler is only invoked after the user is redirected to the login page and submits a (successful) login. So the sequence is
        1. User attempts to access secured resource and an exception is raised
        2. ExceptionTranslationFilter does its stuff (including storing the request)
        3. AuthenticationEntryPoint redirects user to login page
        4. User submits login
        5. UsernamePasswordAuthenticationFilter (UPAF) notes that it is a login request
        6. UPAF authenticates the user via the AuthenticationManager
        7. UPAF invokes the AuthenticationSuccessHandler
        8. The AuthenticationSuccessHandler decides where the user should be redirected to
        9. UPAF returns

        Hope that helps.

        Comment


        • #5
          Hello Luke,

          Originally posted by Luke Taylor View Post
          Hope that helps.
          Yes it does and makes sense, my head was in a different mode since I am working on a solution for API calls using a "fail" or "pass-through" approach. There will be no redirects or anything, its simply a 401 error if the APIKEY is wrong.

          Hence I was observing a different behavior.

          Thanks,
          Serge

          Comment

          Working...
          X