detect exiting the website

[Sean Kinsey]

On Apr 9, 10:13 am, Jorge wrote:

 > > Don't do that either. --Antony
 >
 > So, what do you propose to ping the server from onunload ?

Sean's approach seems to be:

   1. On navigating away from a page in the application,
      send the server a message saying that you can
      terminate my session now.

   2. But if you've navigated to a page in the same app,
      then send the server a message saying `Hey, I haven't
      really navigated away, disregard my last message!'

That's got to be asking for trouble. My apologies if I've
misunderstood.

As I said, read the thread. Then perhaps you would have picked up on
this being a single page app, where only one instance is allowed at
any time, and so the only time this happens is when someone exits the
application without using the signout button.
And to clarify the steps
The server maintains a list of sessions, the clients pings the server
on intervals and extends the session. When the session expires it is
pruned.
1. On unload (close, navigate etc.) send a message to the server and
tell it to set the session to expire in e.g 10 secs
2 If it was only a refresh, then one of the first step the app takes
on load is to ping the server, and hence the session is restored.

It would be safer to start pinging the server as soon as you
connect to a page to let it know that you are still
connected. But why bother? If server resources are so low
that terminating users' sessions after two minutes (or
whatever) rather than thirty will really make that much
difference, then the problem lies elsewhere. It's the
server's responsibility to maintain its own resources. --Antony

This is not to save resources, this is to only allow a single sign on
at any time, and the only extra step here is actually the the single
call to shorten the expiration time.
And to prove that it enhances the user experience; in the worst case
scenario, if the server has just been pinged and the user accidentally
closes the browser, then they would have to wait for the session to
expire before being allowed back in.

I'm pretty sure we know what where doing here, so any criticism needs
to be specific and not based on some generalized notion of what is
'good' and what is 'bad'

 

[Scott Sauyet]

Sean's approach seems to be:

   1. On navigating away from a page in the application,
      send the server a message saying that you can
      terminate my session now.

More like: send the message that it looks as though I'm leaving
without logging out so set my session to expire more quickly than
normal.

   2. But if you've navigated to a page in the same app,
      then send the server a message saying `Hey, I haven't
      really navigated away, disregard my last message!'

Right, and reset the normal expiration time.

That's got to be asking for trouble. My apologies if I've
misunderstood.

I understand it differently. I think I've been in the same position
as Sean. My apologies as well if it's my interpretation that is
wrong.

There's a slight risk of bad timing logging off a user who is still
actively using the system. But that must be balanced against the much
more likely risk of having a user shut out of the system until the
session expires.

It would be safer to start pinging the server as soon as you
connect to a page to let it know that you are still
connected. But why bother? If server resources are so low
that terminating users' sessions after two minutes (or
whatever) rather than thirty will really make that much
difference, then the problem lies elsewhere. It's the
server's responsibility to maintain its own resources. --Antony

I doubt it's a matter of server resources. In a lot of systems I've
worked on (although I've never designed this part of the system) a
user is allowed only one logged-in session on the server. If the user
forgets to log off, she cannot get back on until that session
expires. But the session timeout is set to expire after, say, thirty
minutes of inactivity so that users working on the system are not
being booted too frequently because of distractions at their desks.
This works fine as long as users log off before leaving. But if they
close the browser or in some other way sever the connection with the
session, things fall apart: they have to wait up to thirty minutes to
log back on. In an environment when this application is much of the
main responsibility of that user, thirty unproductive minutes is
unacceptable.

That's what a technique like this is designed to solve. The 30-minute
server session is the default. Any activity resets that timeout, as
do, perhaps, some occasional pings. But on page unload, an attempt is
made to determine if the user is navigating within the system. If
not, the session is set to expire quickly so that the user can log
back on soon. If they are within the system, the normal timeout is
restored.

I've seen many attempts to solve this problem, none of which is
entirely acceptable; I haven't tried Sean's suggestion, but it looks
at least worth an attempt.

-- Scott

 

[Scott Sauyet]

I understand it differently.  I think I've been in the same position
as Sean.  My apologies as well if it's  my interpretation that is
wrong.

Oops, bad timing. Looks as though I had it pretty close, though.

-- Scott

 

[Sean Kinsey]

Oops, bad timing.    Looks as though I had it pretty close, though..

  -- Scott

Pretty much spot on

 

[Antony Scriven]

[...]
I doubt it's a matter of server resources. [...]

I know, but that's what the OP said.

In a lot of systems I've worked on (although I've never
designed this part of the system) a user is allowed only
one logged-in session on the server.

Sean said it was for single sign-on which isn't the same
thing. But apparently he pretty much agrees with your
description; thanks for taking the time to explain it
clearly.

If the user forgets to log off, she cannot get back on
until that session expires. But the session timeout is
set to expire after, say, thirty minutes of inactivity so
that users working on the system are not being booted too
frequently because of distractions at their desks. This
works fine as long as users log off before leaving. But
if they close the browser or in some other way sever the
connection with the session, things fall apart: they have
to wait up to thirty minutes to log back on. In an
environment when this application is much of the main
responsibility of that user, thirty unproductive minutes
is unacceptable.

[...]

If the goal is simply to have one open session, then close
the original session if the user needs to log in again
before it has expired. You can give the user the option to
terminate the first session or cancel the second log in.
This is also a good time to allow a user to report any
fraudulent activity. And a message about misuse at this
point is a good way to discourage password sharing, for
example. --Antony

 

[Jorge]

If the goal is simply to have one open session, then close
the original session if the user needs to log in again
before it has expired. You can give the user the option to
terminate the first session or cancel the second log in.
This is also a good time to allow a user to report any
fraudulent activity. And a message about misuse at this
point is a good way to discourage password sharing, for
example. --Antony

That's true. And I'm going to borrow the idea.