Announcement Announcement Module
Collapse
No announcement yet.
ConcurrentSessionFilter and cluster-aware SessionRegistry Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • ConcurrentSessionFilter and cluster-aware SessionRegistry

    Hey folks,

    I'm trying to prevent concurrent sessions using Spring Security in a webapp that will run on a server cluster. I'm using my own SessionRegistry, that stores all SessionInformation in a database, so all servers share the session information.

    The first problem I came across was, that when a session expires by calling SessionInformation.expireNow() the SessionRegistry does not get informed and so the database gets not changed and the other servers never know, that this session expired. I solved this with my own subclass of SessionInformation, that informs the SessionRegistry, which then marks the session as expired in the database.

    Now to my current problem: If a session expires, because the user logs in a second time, it gets marked as expired in the database. However, as long as nobody tries to continue this session, it never gets destroyed and remains in the database forever.

    A solution would be, not to store expired sessions in the database, but just delete them. But then the SessionRegistry would have no information about the expired session and the ConcurrentSessionFilter wouldn't work properly, because of the if-statement in line 84.
    Code:
    if (info != null)
    This if-statement does not have an else-branch, so the ConcurrentSessionFilter does nothing, if there is a session in the HttpRequest, but no SessionInformation in the SessionRegistry. Shouldn't the ConcurrentSessionFilter do something in this situation? Or am I missing something?

    Any ideas are appreciated.

  • #2
    Hi Christopher,

    I’m also looking for a cluster aware concurrent session solution. And there are couple of solutions, store session in a clustered memory object (ehcache or similar) or in a central datastore. I’m also interested in your datastore solution, could you share it with us?

    And as far as I can see the ConcurentSessionFilter searches for other concurrent sessions for the same user and marks that session for logout ("expire") (or prevents login). So it needs to keep the expired sessions in the SessionRegistry to force a logout on the next request of the concurrent session (ConcurrentSessionControlStrategy).
    So if you delete expired sessions immediate you can’t prevent concurrent sessions. That’s why there is no else in the ConcurentSessionFilter, there is noting to do when there is no SessionInformation.

    As far as I can see it works fine and needs to store the expired session if you would like prevent concurrent session with same username. But you have to inform the your custom SessionRegistry when the session is expired by the ConcurrentSessionControlStrategy.

    Kind Regards,
    Ron

    Comment

    Working...
    X