Announcement Announcement Module
Collapse
No announcement yet.
events propagation (new AuthenticationSuccessEvent) Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • events propagation (new AuthenticationSuccessEvent)

    Hello.
    I'm using Acegi 0.8.2 and in order to detect when a user is logs in and out I implemented a listener for AuthenticationSuccessEvent and HttpSession destroy event. As a provider I am using the DaoAuthenticationProvider which , if the cache is used doesn't send an event when the user logs in (unless the cache expires).

    I tried to subclass the authenticate method in order to provide some sort of decoration which should fire the event no matter what but using the current version, one has to rewrite/copy-paste some part for the original code. Why does the caching (which relates to the DB access) affects the logic - caching should be invisible and not affect the application semantics.

    are there any other/better hooks(other events) that I should use that are independent of caching?

  • #2
    Refining the event handling is on my TODO list. For now http://forum.springframework.org/viewtopic.php?t=5136 might give some ideas. Also, subclassing your authentication processing filter (ie http://acegisecurity.sourceforge.net...ingFilter.html) provides an onSuccessfulAuthentication() method which gives you a hook where you could publish an event that indicates an interactive authentication took place.

    Comment


    • #3
      Thanks. What would be the time frame for addressing event handling ?

      Comment


      • #4
        There is no timeframe, although I would expect to have addressed it before 0.9.0 is released.

        Comment


        • #5
          Okay, any ideas when 0.9.0 is going to be out?

          Comment


          • #6
            just my few cents worth -

            I can't see why you would want the AuthenticationSuccessEvent to NOT be published if the cacheWasUsed. It just doesn't make sence.

            Any changes that this can be at least amended in CVS ?

            I am logging these to the database, as well as logout events.

            The issue is that someone can login, logout, login, logout - then in my logs I have login,logout,logout.

            I would subclass the filter - however this will cause duplicate AuthenticationSuccessEvent events due to the initial login event being fired by DaoAuthenticationProvider.

            As a side note - I want to say thanks for your great work Ben - and associates

            Comment


            • #7
              I can't see why you would want the AuthenticationSuccessEvent to NOT be published if the cacheWasUsed. It just doesn't make sence.
              I don't know to whom you are replying but that's the topic of the thread. The events should be published no matter if the cache is used or not.

              I would subclass the filter - however this will cause duplicate AuthenticationSuccessEvent events due to the initial login event being fired by DaoAuthenticationProvider.
              The easiest way in this case is to create a different event in order to avoid duplicates.

              In my case even though I just disabled the cache - this means that on every request the DB will be hit but it's okay since the app is still in development. I'll wait for 0.9.0 to come out and take it from there.

              Comment


              • #8
                Sorry to inconvenience everyone. I have so many projects on at present, three scheduled in a row. I will get to 0.9.0 as soon as I possibly can. As always, I welcome contributions if anyone wishes to see this resolved sooner.

                Comment

                Working...
                X