Announcement Announcement Module
Collapse
No announcement yet.
TokenBasedRememberMeServices has no cache mechanism ? Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • TokenBasedRememberMeServices has no cache mechanism ?

    After I use rememberMeServices,I found these code do execute every request :

    TokenBasedRememberMeServices.java

    Code:
                            try {
                                userDetails = this.authenticationDao
                                    .loadUserByUsername(cookieTokens[0]);
                            } catch (UsernameNotFoundException notFound) {
                                cancelCookie(request, response,
                                    "Cookie token[0] contained username '"
                                    + cookieTokens[0] + "' but was not found");
    
                                return null;
                            }
    I use my own AuthenticationDao to load user from DBMS. So It'll execute query SQL every request!

    Maybe I miss something?

  • #2
    This block of code needs to execute to ensure someone hasn't created their own cookie to gain access. The content of the cookie contains (among other things) the MD5 encrypted password. TokenBasedRememberMeServices needs to access the password in the database, so it can encrypted it and build a token that should match the one in the cookie. Since only the user knows the password, and its encrypted in the cookie, then its difficult to build one from scatch. (Mind you, its possible to steal one and use the stolen one). Once this is done it will eventually get populated in the HttpSession (via HttpRequestIntegrationFilter). The next time through RememberMe won't kick in because Authenticate is in the sesssion. Therefore, the SQL should only execute once per session. Did you forget to chain in HttpRequestIntegrationFilter?

    Its all summed up in this fantastic comment in the code

    Code:
    // Check signature of token matches remaining details
    // Must do this after user lookup, as we need the DAO-derived password
    // If efficiency was a major issue, just add in a UserCache implementation,
    // but recall this method is usually only called one per HttpSession
    // (as if the token is valid, it will cause ContextHolder population, whilst
    // if invalid, will cause the cookie to be cancelled)

    Comment


    • #3
      I use Tapestry + Acegi

      although I configure a "httpSessionContextIntegrationFilter" in my filter chain.
      But I found the session can not be create because the response's commited status is true!!

      Maybe this is Tapestry's Bug?

      I test with a normal JSP page,and it works !

      Comment


      • #4
        There is no caching in the remember me processing filter, because it should only execute once per user session. If the user gets remembered, the new Authentication will be placed onto the ContextHolder and further remember me processing is unnecessary. Switch on your DEBUG-level logs and you can confirm this.

        Comment

        Working...
        X