Announcement Announcement Module
Collapse
No announcement yet.
Using the usercache, best practices Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Using the usercache, best practices

    Hi all,
    I am working on an application and I am using acegi for security mechanism. I have created my own AuthenticationDao and am using hibernate for persistence of my used data. But that is not my problem. Since I am trying to optimize performance I want to use caching as well. I see there are some threads about caching allready, but I cannot find what I really want.

    What I want is remove a user from the cache, or update the cache if a user uses the form to logon. This way I can show him the new date/time of his last logon date. Within version 0.9.0 there is a new Event mechanism, but I am not sure whether to use this mechanism. I see an AuthenticationSuccessEvent and an InteractiveAuthenticationSuccessEvent. Cannot see the difference actually. Should I use this event to access the UserCache and remove the user, or will the user not be updated again into the cache. The event is raised after the user is put into the cache. What I thought about is using a custom AuthenticationProcessingFilter. This object knows when an authentication form is entered, this could be a good moment to clear the cache for the current user. However this could mean if someone uses the wrong username, he can invalidate the cache for another user.

    So what is my questions, i want to hear your opinions about where to solve the caching problem. I would love to have something out of the box, ie supported by the framework.

  • #2
    I would recommend you do not use UserCache at all.

    Hibernate offers a second level cache which is a more logical place to plug in. In addition, in 0.9.0 the user is not reauthenticated on every secure object invocation, which dramatically reduces the justification for caching if it you have complicated element eviction requirements.

    InteractiveAuthenticationEvent is fired whenever an authentication mechanism authenticates a user. AuthenticationSuccessEvent is fired whenever an AuthenticationProvider (via ProviderManager) authenticates a user. Sometimes people want to differentiate how and why an authentication took place. For 80% of deployments, it's probably best to use the AuthenticationProvider created events, as they're more finely grained.

    Comment


    • #3
      Thank you for your reply. Based on your remarks I will remove the cache then.

      Comment


      • #4
        Invalidation of User with CAS based providers...

        I had gotten comfortable with the usercache in Acegi and was wondering why my 0.9 based Acegi was not hitting the DB even though I nulled the cache. I puzzled over this for a while.

        Anyway, I have a requirement to 'invalidate' a user's context if there is an update to the backing data. For example, I lookup some data and store it in user details. In the old days, I would have invalidated the cached user to force the next auth cycle to pull in a fresh user + user data. How do I do this now?

        I guess I mean, how do I programatically invalidate the user's context to cause a readthrough by the authorities provider?

        I'm using CAS if this matters...

        Comment

        Working...
        X