Re: Single terminal login

[Ingo Struck <ingo () ingostruck de>]

Hi...

> The approach where you simply invalidate any existing sessions when
> users log on again is not such a bad one.
I highly agree with Rogan, and from my experience would say that this
in conjunction with a session expiration is *the only* viable solution.

The arguments that Rogan introduced are already strong:
- most users don't log off after having done their work
- most often you need a server-side sid->user mapping anyway
- concurrent logins certainly do not go unnoticed - if you keep track
  of the different "logout"-modes, i.e. 1.) user log off 2.) expiry 3.) forced
  log off due to re-login you can even explicitly pass that information to
  the user

I would like to add that a session expiration is absolutely necessary
- to keep your system clean (since really most users don't clean up
  their stuff themselves, both in real life and in web apps)
- to reduce the risk of session hijacking due to "forgotten" sessions

From the system's point of view the former is much more important
than the latter.

All other solutions with cookies and login-locks bring about all the
problems you and other people already described: stale sessions,
users locking themselves of and the like.

If you have users sharing accounts, then it's time to educate them
about what an account means and not to introduce inappropriate
"technical" countermeasures.
(e.g. tell them "From now on we'll charge a buck from a credit card 
bound to an account for each login" - if you really did that, you'd see
how fast they all get their own accounts... ;) )

The implementation that Michael Silk outlined is the usual one.
However, I tend to bind the expiration to the session like all j2ee servlet
engines do (even though I generally don't use the built-in session 
mechanisms). And by the way I tune the timing granularity such that
the expiration time does not vary more than about 10%, i.e. if you have
a session lifetime of 30 minutes, you need a cleanup every 3 minutes.

If you are interested in a rather clean and well-tested timeout/watchdog
mechanism for java, then have a look at OWASP's Common Library
(cf. http://www.owasp.org/development/ocl), preferably the CVS version.
Look at the package org.owasp.util classes Finalizable, Finalizer, and 
Lapsable and at org.owasp.model.connect class Session for an example
how to implement session timeouts.
In addition to the timeout mechanism these classes provide for finalization
that is guaranteed to be invoked upon JVM shutdown (contrary to default
garbage collection).

HTH and kind regards

Ingo Struck