Monitoring logged-in users with sessions: autologoff

[vesely]

Hi all,
I'm currently relying on logged-in users hitting "logout"
(logoff) before they leave, in order to terminate the session.

With PHP the session filename is in a cookie that lasts for the
current session. The problem is that the server does not know
when the current session expires. (I have quite long timeouts.)

Did anybody attempt a script to automatically call "logout"
when the session expires? It seems quite complicate, as there
are multiple urls that share the same session and the user is
not actually logging out until one of them is open in some
client window.

Any better ideas?

TIA
Ale

[Gordon Burditt]

>I'm currently relying on logged-in users hitting "logout"

(logoff) before they leave, in order to terminate the session.

With PHP the session filename is in a cookie that lasts for the
current session. The problem is that the server does not know
when the current session expires. (I have quite long timeouts.)
Then keep track of the timeout yourself.
When the user logs in successfully, set $_SESSION['last_hit']
to the current time. When the user hits a page, check his
login INCLUDING that $_SESSION['last_hit'] being not too old.
If it is too old, redirect to the login page.

If the session is valid, and you want to count the timeout from
the last hit, not the time of login, set $_SESSION['last_hit']
to the current time.

Did anybody attempt a script to automatically call "logout"
when the session expires?

You can't send a page to the browser spontaneously.
You can invalidate the login. With the above procedure,
you don't have to actually DO anything to expire the session
at the time it expires, just check if it has expired at
each page hit.

Gordon L. Burditt

[vesely]

Yup, I'm keeping track of login and last_hit times. However, the server
is not able to distinguish between a user who is taking a long time to
post an update from a user who killed the browser window without
hitting logoff. (The purpose is to just warn them when more than one
is updating the same data.)

You can't send a page to the browser spontaneously.

I could use the onBlur feature to automatically load logoff.
Perhaps I could use a frame, where an invisible page stays there
just to confirm that the user's session is still valid. Many sites,
e.g. PostNuke, display to a user what other users are currently
logged on, so I don't want to reinvent the weel...

[Gordon Burditt]

>Yup, I'm keeping track of login and last_hit times. However, the server

is not able to distinguish between a user who is taking a long time to
post an update from a user who killed the browser window without
hitting logoff. (The purpose is to just warn them when more than one
is updating the same data.)
If you are really trying to track simultaneous updates to the same
data, you need a lot more than login information. And isn't the
time to do this when the user submits the conflicting change?

What's your purpose in trying to tell when a user has "logged off"
(whatever that means)? Invalidating a session after a certain amount
of time addresses the "unattended keyboard" security issue (and
doesn't require dealing with the browser at all). If this isn't the
point, what is?

You can't send a page to the browser spontaneously.

I could use the onBlur feature to automatically load logoff.

It's this sort of thing that is a major reason Javascript is Turned Off(tm).
Perhaps I could use a frame, where an invisible page stays there
just to confirm that the user's session is still valid. Many sites,
e.g. PostNuke, display to a user what other users are currently
logged on, so I don't want to reinvent the weel...

If your purpose is to display who's logged on, that info is suspect
at best. You can't tell the difference between someone who is still
entering an update and one who has been arrested (leaving his browser
open) and is serving a life sentence, except by the magnitude of
the idle time. Oh, yes, there's also computers crashing, power
failures, and suddenly getting disconnected from the Internet via
dialup lines (call waiting, line noise, someone picks up extension
and starts dialing, etc.).

I suspect those sites displaying users logged in are using timeouts
and not worrying too much about accuracy.

Gordon L. Burditt

[vesely]

>> (The purpose is to just warn them when more than one

is updating the same data.)

If you are really trying to track simultaneous updates to the same
data, you need a lot more than login information. And isn't the
time to do this when the user submits the conflicting change?
I used to provide for sending data's timestamp as a hidden field
and checking it before executing the update when it comes back.
It is an expensive style of coding, not always strightforward,
and seldom firing: users often work in the same office, know
what everybody else does, and apply human reasoning. Thus I've
decided I'll just warn them if they enter in the same logic area.
One logic area has its own cookie name and corresponding list of
sessions. The server maintains a session-group's list in a file
named after the cookie: on each request, the server deletes from
the list any session-id whose corresponding file doesn'exist any
more.

The other use of sessions is to store confirmation messages,
e.g. "your move operation succeeded: it moved 24 items".
Concurrency warnings, e.g. "user smith logged off at 10:44:35,
no other user is logged on", are appended to confirmations.

The resulting code is quite compact and smoothly portable to
different logic areas. One difficulty is adding the logoff link
to every page, which increases the likelyhood that the user
does not logoff... :-(
You can't tell the difference between someone who is still
entering an update and one who has been arrested (leaving his
browser open) and is serving a life sentence
However, the prisoner can get a mercy or ask to a relative to do
something with the browser for him. After the browser dies, there
is no way to reach the session on the server, except searching
all sessions in a group for the given user-id. That way a user can
delete all non-current sessions he owns, i.e. all sessions having
his user-id except the one issuing the "force logoff" command.
I suspect those sites displaying users logged in are using timeouts
and not worrying too much about accuracy.

Yes, and probably they have short (~300 secs) timeouts. I will wait
until next day, still shorter than life sentences, in most cases :-)