Hi folks, Is it not safe to store references to the session as long as you remove your references (if you still have one) when sessionDestroyed in HttpSessionListener is called?
For this, I’d keep a Map of user -> session and when a new user logs in, I’d put the new session to the map and if map put call returns a session, invalidate it. Just make sure you when you remove the user/session from your user/session map in sessionDestroyed you use: default boolean remove(Object <https://docs.oracle.com/javase/8/docs/api/java/lang/Object.html> key, Object <https://docs.oracle.com/javase/8/docs/api/java/lang/Object.html> value) ... to make sure that the user is only removed if that session hasn’t been overwritten. I think this is safe as this way the session reference is only kept whilst the user is logged in and the server hasn’t killed the session.... but maybe I’ve misunderstood...? Or maybe I’ve just described Jan’s final approach? I ask because I do hold session references to be iterated over periodically for a session timeout that excludes some requests from resetting the timeout and perhaps I shouldn’t!? Gordon On Fri, 30 Apr 2021 at 01:04, Jan Bartel <[email protected]> wrote: > Hi Silvio, > > The HttpSession is a server object and thus its lifecycle is managed by > the server. Applications should not try and hold references to these > objects, as you've discovered ;) > > There isn't an api provided by the spec that would allow you to randomly > access any session by its id. I wouldn't encourage you to try and use any > jetty-specific apis to do that either, as once again you could wind up in a > mess trying to manage session lifecycles that are designed to be managed by > the container. So I don't see any easy way of proactively invalidating and > removing a session that is not part of the current request. > > Instead, you could investigate an approach like: > > + set a reasonably short timeout on sessions (tuned to your app's usage): > if the user logs in again somewhere else and never refers to that session > again, it will timeout > + keep a map of user -> sessionid that is the currently "valid" one, and > use a filter in your app to check if the user,sessionid tuple of the > current request is in that map; if not, invalidate the session or just > reject the request and let the session timeout > > An alternative approach would be to do a custom LoginService or jaas > LoginModule that prevented a subsequent login if the user is already logged > in. You would still need to manage and consult your own map of logged-in > users. > > cheers > Jan > > On Thu, 29 Apr 2021 at 23:32, Silvio Bierman <[email protected]> > wrote: > >> Hello all, >> >> This might be a generic servlet question but since Jetty (10.0.2, >> embedded mode) implements otherwise unspecified behavior I would like to >> ask this here anyway. >> >> I am trying to setup a scheme where user can be limited to no more than >> one logged in session at the same time. Any existing session for a >> particular user that logs in should be invalidated making the last >> session the only valid one. Somehow I need to manage a mapping from user >> name to some session referencing information that represents currently >> active sessions and allows me to invalidate a session. I did a >> quick-and-naive implementation using a WeakValueMap that maps the user >> name to a weak reference to a HttpSession object. Unfortunately, that >> showed very erratic behavior (existing session where not in the map) >> that I at first could not explain. I decided to try what happened when I >> use the HttpSession objects themselves as mapped values. That worked. I >> suspect that the HttpSession objects could be more temporary than I >> thought that validity of a HttpSession object is only guaranteed during >> the lifetime of the HttpServletRequest object that it was obtained from. >> That makes perfect sense and explains what I observed. >> >> But now my question is: how can I achieve my goal? I can map user names >> to session IDs but have no way of accessing the related sessions, other >> than using the ID to make up some request that is handled by >> invalidating the then accessible session. This seems rather clumsy and I >> am hoping there is a better way to do this. >> >> Any suggestions would be welcome. >> >> Thanks, >> >> Silvio >> _______________________________________________ >> jetty-users mailing list >> [email protected] >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users >> > > > -- > Jan Bartel <[email protected]> > www.webtide.com > *Expert assistance from the creators of Jetty and CometD* > > _______________________________________________ > jetty-users mailing list > [email protected] > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users >
_______________________________________________ jetty-users mailing list [email protected] To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
