Posted by Richard Levasseur on 11/18/17 11:40

Jasen Betts wrote:
> On 2006-02-19, Mickey <mickey.allroid@gmail.com> wrote:
> > Thanks to all for the replies.
> >
> >> Now, if you keep the 'last heard from' timestamp in a database, you may
> >> release a session based upon a last response time (i.e. fifteen minutes)
> >> without having to hear from the browser at all. (i.e. no cookie exchange
> >> is required) Its not the same as detecting that they have gone elsewhere
> >> but is probably the best you can do.
> >
> > This is interesting.
> > Currently I am storing the 'last heard from' timestamp in a database
> > and if the user refreshes their browser and a specified amount of time
> > has passed then they are directed to re-login.
> > However, if the user closes their browser, I need to be able to clean
> > out the database of currently logged on users. I can't do this if the
> > user doesn't refresh their browser.
>
> why can't you? all that's needed is
>
> delete from sessions where last_access < now - INTERVAL '0:15:00';
>
> or similar.
>

The problem is he can't be notified - for sure - when they leave his
website, so he doesn't know when, exactly, to run that query. Deleting
old session every page hit would catch 15 minute time outs immediately,
but not the instance of if they close their browser/leave his website
(as you say below). Additionally, if no one hit the page the database
wouldn't be updated (which may or may not be important, can't tell from
what he's said so far). Then, eventually, though unlikely, all 5
logins would fill up and the user would be locked out until one of
those sessions timed out.

> > Ultimately, this is what I am trying to do, and also delete this user
> > from the list of currently online users. Can this be done once the user
> > has left the page or is there a better way to acheive this?
>
> it's hard to determine when a user leaves.
>
> Bye.
> Jasen

Agreed. Again, because of the nature of HTTP, you generally will not
know when they run leave your server (thats the worst thing about
webdev, absolutely no client - server trust :( ).

Another alternative to using javascript/java to maintain a heartbeat
back to your server would be to have a cron-job run every few minutes
and run the above query to update the database. You don't have the
advantage of immediate update on every page hit, but then again you
don't have the load of updating the database every page hit.

Generally, imo, i just allow a single session for a user, as multiple
tabs/dervied windows are the same session, using timeouts for when a
record needs to be locked for editing by a single user.

I believe there was another thread on a topic similar to this, and,
iirc, one proposed solution was to keep track of the previously logged
in session ID, and on new log ins, delete the old session and set the
old id as the new id (in fact, i think i made the post on that, i can't
recall exactly). This concept could easily be extended to allow some
arbitrary amount of session for a simultaneous login limit.

[Back to original message]