Thanks Jan... I’ll revisit my design!! Gordon
On Sun, 2 May 2021 at 08:15, Jan Bartel <[email protected]> wrote: > Hi Gordon, > > You really shouldn't be holding references to the HttpSession in between > requests - there's no guarantee that when an app calls getSession() on each > new request that you will get back the same session object. I haven't > checked but I'm not even sure that if you call get Session() twice for the > same request that there's any guarantee that you'd get the same object. > Certainly if you've configured the NullSessionCache the object is not > shared at all. If you're using the DefaultSessionCache you've got a good > chance that you'll get back the same object, but not guaranteed because the > session many have been passivated out eg if you're using idle eviction. > > Managing the lifecycle of the HttpSession is a tricky business and jetty > is working hard behind the scenes to maintain consistency and integrity - > hanging on to object references either won't work as you expect or won't > work at all. > > Cheers > Jan > > > > On Sun, 2 May 2021, 09:21 Gordon Jahn, <[email protected]> wrote: > >> 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 >> > _______________________________________________ > 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
