Re: [jetty-users] HttpSession object lifetime

[Jan Bartel <janb@xxxxxxxxxxx>]

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, <gjahn@xxxxxxxxxxxxxxxxx> 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 key,
                       Object 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 <janb@xxxxxxxxxxx> 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 <sbierman@xxxxxxxxxxxxxxxxxx> 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
jetty-users@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users

--

Jan Bartel <janb@xxxxxxxxxxx>

www.webtide.com
Expert assistance from the creators of Jetty and CometD

_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users

_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users