Announcement Announcement Module
Collapse
No announcement yet.
SavedRequestAwareAuthenticationSuccessHandler.requ estCache not exposed Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • SavedRequestAwareAuthenticationSuccessHandler.requ estCache not exposed

    I would like to override the onAuthenticationSuccess method of this class, to implement some business based logic, which would redirect the authority based on their role, however, in the case where the cached request (SavedRequest) is not null, then simply redirect to the orginally cached url. However, since the savedRequest var isn't accessible is the AuthenticationSuccessHandler the right place to intercept & redirect the request based on authentication's role?

    This isn't a problem if the user is authenticating normally (i.e. index.html), but in the case where they have a bookmarked page, for instance, Spring security will save the original request, and then redirect them to the bookmarked url after authenticating...

    Any advice on how to redirect based on granted authorities, but only if the SavedRequest is null?

  • #2
    See if this thread helps.

    Comment


    • #3
      Originally posted by rwinch View Post
      See if this thread helps.
      Doesn't solve the inaccessible SavedRequest requestCache instance field on SavedRequestAuthenticationHandler.

      For example. User has bookmark to /webapp/gotoA.htm, so then the click on it, Spring forces authentication: onSucccessfulAuthentication(or whatever) is fired, we check the user's authorities (he's admin), and we redirect them to /webapp/admin.htm. but he really wanted to go to /webapp/gotoA.htm, which is in the super.requestCache field (set by Spring prior to authentication).
      Last edited by denlab; Jun 24th, 2011, 12:20 PM.

      Comment


      • #4
        I "solved" my problem by introducing a SavedRequest field on my implementation of SavedRequestAwareAuthenticationSuccessHandler, and adding a setter method for it. Spring now sets the field with the saved request, and it's available when the onAuthenticationSuccess fires in my impl.

        Thanks.

        Comment


        • #5
          I'm glad you solved your problem. The thread I posted solves the problem without even needing access to the default request. Instead the code that processes the default-target-url looks to see what role it is and then forwards onto the appropriate view. This has the advantage that it does not need to be coupled to Spring Security.

          Comment

          Working...
          X