Announcement Announcement Module
Collapse
No announcement yet.
Concurrent Logins -- Is it in 0.8x? Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Sounds perfect.

    Originally posted by David Carter
    This introduces a new configuration variable disallowLogin to determine whether we throw an exception, or silently invalidate the least-recently-accessed session.

    The invalidateLRUSession(principal) method would iterate the principal's sessions, finding the session with the lowest getLastAccessedTime() value & calling invalidate() on it.

    Does this seem like a workable approach?

    Comment


    • #17
      Originally posted by David Carter
      This introduces a new configuration variable disallowLogin to determine whether we throw an exception, or silently invalidate the least-recently-accessed session.
      How about reporting back to the user that an existing session with their credentials exists and then give the user the option to terminate the existing session. Also, notified the user of the existing session that someone has attempted to login using their credentials.

      Comment


      • #18
        Any idea when this new concurrent login behaviour that we've agreed upon is going to make it into Acegi?

        Thanks,
        Sanjiv

        Comment


        • #19
          I apologize for my huge delay on this thread, but I've been kinda busy :P

          OK, I was just looking over this idea so that I can code it up...

          There's the problem with this alternative behaviour. The ConcurrentSessionControllerImpl does not track HttpSession objects, it only tracks sessionIds. In fact, it doesn't even have access to the sessions, it gets the sessionId from the Authentication.getDetails() method.

          Comment


          • #20
            Hi Ray, is there a way forward on this (refactor, minor feature, don't provide the extra capability/feature)?

            Comment


            • #21
              In order to track sessions in a "last one active" sort of fashion we'll need access to the sessions themselves, not just sessionIds. Our AuthenticationManager approach didn't take this into consideration. It was designed to operate with the Principal as the focal object. We are really going to need an approach that uses the HttpSession object as the focus.

              An implementation that focuses on HttpSession seems best implemented as a Filter, not as an extension to the AuthenticationManager. The really unfortunate part is that it would seem sort of lame to have to configure the session control stuff at the AuthenticationManager if you want it one way, and at the web.xml level if you want it the other.

              The ConcurrentSessionContoller implementation we have now does listen for the HttpSessionCreatedEvents. Although, that is ureliable at best because we never actually create sessions in the HttpSessionContextIntegrationFilter until after the request.

              A filter based approach would be relatively simple. It would unfortunately be a completely different configuration than the AuthenticationManager approach.

              Comment


              • #22
                Wouldn't a HttpSession exist by the time of the actual authentication attempt, because AuthenticationProcessingFilter passes the HttpServletRequest to the WebAuthenticationDetails constructor, and internally it performs a request.getSession() which should create a HttpSession if it doesn't already exist?

                The only reason I can see there is any desirability of having the HttpSession available for concurrent session enforcement logic is to select the particular existing session to be invalidated on a least recently used (LRU) basis. I personally believe that most applications using concurrent session control would only be permitting a single login per username anyway, so it's clear which session should be eliminated in probably 80% of use cases (specifically, the opposite one to that of the current request).

                The actual implementation of LRU selection logic doesn't seem to be of critical importance AFAICS, provided that it does a "reasonable job" of selecting the LRU session. Using request.getLastAccessedTime() is a good way of selecting the LRU session, but it would impose a departure from the current design as noted by Ray.

                For the majority of applications desiring concurrent session control with a maximum session count exceeding one (and can live with a "reasonable job" LRU handling approach), what is wrong with another Map that stores <DateOfLastAuthentication:SessionId>? The only slight reduction in robustness over using HttpSession directly is that the LRU date is based on authentication activity instead of simply requests to the web container. Applications wishing to enforce concurrent session logic probably mainly perform requests for secured resources anyway. So it seems to meet most requirements, and is a "reasonable job" of LRU handling that doesn't require yet-another-filter. I believe the marginal extra value of request.getLastAccessedTime() isn't worth adding another filter for. Recall that applications really needing absolute LRU precision could implement such a filter, or, more simply, a hidden IFRAME that uses a META refresh to re-poll a secured resource every few minutes as a "session keep-alive".

                Thoughts?

                Comment


                • #23
                  Just a further thought... Why not make a SessionRegistry interface and class that is defined as a separate bean to the ConcurrentSessionControllerImpl. Thus people can write a Filter (or MVC controller or anything else they like) to update the last accessed time. For those people who don't need such precision, they can just use the default handling of updating it during each authentication.

                  Comment


                  • #24
                    Originally posted by Ben Alex
                    The only reason I can see there is any desirability of having the HttpSession available for concurrent session enforcement logic is to select the particular existing session to be invalidated on a least recently used (LRU) basis.
                    Do we have a way to perform an invalidate() on the LRU HTTPSession? AFAIK, this is a method on the same interface as getLastAccessedTime(). Is there another way to accomplish the invalidation of the other session via ACEGI's APIs?

                    I think selecting the LRU session based on the last authentication request is a reasonable approach.

                    Comment


                    • #25
                      Originally posted by David Carter
                      Do we have a way to perform an invalidate() on the LRU HTTPSession?
                      Sounds like a useful method for the SessionRegistry class, along with something to obtain "all this user's current/active sessions". Might be worth recording their IP addresses as well, so a table can be shown to the user so advanced deployments can select which session to invalidate...

                      Originally posted by David Carter
                      I think selecting the LRU session based on the last authentication request is a reasonable approach.
                      Excellent.

                      Comment


                      • #26
                        Originally posted by Ben Alex
                        Sounds like a useful method for the SessionRegistry class, along with something to obtain "all this user's current/active sessions".
                        Yes, that would be useful.

                        Originally posted by Ben Alex
                        Might be worth recording their IP addresses as well, so a table can be shown to the user so advanced deployments can select which session to invalidate...
                        This could also be useful. A related requirement I often see is the need to persist to the database the last login date/time & IP address. Displaying this to the user each time he logs in can be a useful way of detecting unauthorized access. Where's the best place to implement this in the Acegi architecture?

                        Comment


                        • #27
                          I don't think I explained one of my points well enough. Not having the HttpSession instance means we cannot use the getLastAccessedTime(), true. More importantly, without the actual HttpSession instance there is nothing for us to invalidate(). The ConcurrentSessionControllerImpl only has access to the Authentication object.

                          Comment


                          • #28
                            But why do we need to invalidate the HttpSession at all? We could simply record it was "replaced by another session". That way when the user next makes a request from a replaced session, they don't see a fresh authentication process - instead they see a nice description of what happened.

                            Comment


                            • #29
                              A further concurrent session related thread is at http://forum.springframework.org/showthread.php?t=14742.

                              It might be worthwhile if refactoring ConcurrentSessionControllerImpl to maintain a concurrent application-wide session maximum. This would be useful to applications deployed in circumstances where only a certain number of concurrent users are allowed. To make this useful for single applications, multiple subscriber situations (ie ASP deployments) we'd probably need to store a map of sessions against a subscriberId key. For non-ASP environments the subscriberId would always be some constant. For ASP environments, developers would implement an interface (public Serializable getSubscriberId(Authentication)) that return an Object to be used as the subscriberId key.

                              I think concurrent session support - if done properly - could be a major value-add for Acegi Security users.

                              Thoughts?
                              Last edited by robyn; May 14th, 2006, 11:07 AM.

                              Comment


                              • #30
                                More concurrent session requirements: http://forum.springframework.org/showthread.php?t=14830

                                It's good all these requirements can be collected here together in this thread prior to refactoring.
                                Last edited by robyn; May 14th, 2006, 11:04 AM.

                                Comment

                                Working...
                                X