Posted by Alan J. Flavell on 03/25/06 17:57

On Sat, 25 Mar 2006, Jose, in an unattributed quote:

> > To answer your question, you need to change the session lifetime
> > so it does not expire before your user finishes reading a page.

This doesn't really make sense. There's no logical reason - until you
artificially invent a reason - why a reader shouldn't start reading a
page before going to bed, and continue reading it after a good night's
sleep. Equally, they might quit the browser after 30 seconds with no
intention of ever returning. In either case there's no reason that
the server needs to get to hear about it. There simply is NO correct
value to use for a session timeout. Every choice is a compromise,
which is going to be wrong at least as often as it's right, IMNSHO.

> However, presumably if he's using sessions to begin with, the
> purpose is to expire a session in case the user just wandered off
> without logging off.

The questioner would need to ask themselves what is the purpose of
this. If they're trying to protect themselves from the user wandering
off and letting some unauthorised person perform actions in their
name, there isn't a great deal they can do, short of demanding
credentials *at the point of carrying out the action*, rather than
relying on some established session credentials. And even that will
be subverted if the user has taken the option to have their browser
remember their credentials for next time.

Usually the question is "who has the most to lose?". If the user has
more to lose, then maybe you should be advising the user on ways to
protect themself (e.g lock their keyboard when going for coffee,
whatever), rather than trying to be over-protective on their behalf.

But if the user has nothing to lose by casually letting intruders
perform actions in their name, it's logical for you to look for ways
of protecting /yourself/ against such misuses.

> There may be no magic number. (i.e. most users who abandon without
> logging off do so after five minutes, but those who stay will stay
> for twenty while reading stuff).

Indeed. And - just to take one practical example - when I'm trying to
plan a trip with some journey planner, I might need to have
discussions in the middle - checking with a colleague to see if the
arrangements are OK, or checking up with the organisers if an extra
day's stay seems necessary; it's simply *maddening* to be told, when
trying to resume the planner, that the session has timed out and
please to start again from Square One.

> If leaving an abandoned session open is sufficiently risky, then the
> original question remains.

Quite. But as I say, "risky" to whom? That may be a clue towards
optimising a solution.

IMHO this isn't just about getting a piece of code from somewhere and
applying it. There are countless more-or-less-satisfactory pieces of
session manglement code floating around, that purport to do something
not entirely unlike what one is trying to achieve; but until you're
clear in more fundamental terms what it is that you need, it's hard to
really evaluate them. You risk just annoying your users, to no good
purpose.

[Back to original message]