detect exiting the website
in [JavaScript]
|
From: Antony Scriven on 9 Apr 2010 07:31 On Apr 9, 10:13 am, Jorge wrote: > On Apr 9, 10:26 am, Antony Scriven <adscri...(a)gmail.com> > wrote: > > > On Apr 8, 9:37 pm, Jorge wrote: > > > > On Apr 8, 10:18 pm, Antony Scriven > > > <adscri...(a)gmail.com> wrote: > > > > > > > On Apr 8, 7:00 pm, Jorge wrote: > > > > > On Apr 8, 5:45 pm, Antony Scriven > > > > > <adscri...(a)gmail.com> wrote: > > > > > > > > > Synchronous requests don't tend to improve the > > > > > > user's experience. --Antony > > > > > > > > > > But onunload you can't do an asynchronous XHR. > > > > > > > I wasn't talking about asynchronous XHR. --Antony > > > > > > But any other attempt to fetch an additional resource > > > onunload might fail. I.e. an <img>. E.g. in Safari. > > > 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. 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
From: Sean Kinsey on 9 Apr 2010 09:05 On Apr 9, 1:31 pm, Antony Scriven <adscri...(a)gmail.com> wrote: > On Apr 9, 10:13 am, Jorge wrote: > > > On Apr 9, 10:26 am, Antony Scriven <adscri...(a)gmail.com> > 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' ;)
From: Scott Sauyet on 9 Apr 2010 09:28 Antony Scriven wrote: > 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
From: Scott Sauyet on 9 Apr 2010 09:37 Scott Sauyet wrote: > 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
From: Sean Kinsey on 9 Apr 2010 09:50
On Apr 9, 3:37 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote: > Scott Sauyet wrote: > > 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 Pretty much spot on ;) |