detect exiting the website
in [JavaScript]
|
From: Hamish Campbell on 7 Apr 2010 22:42 On Apr 7, 7:25 pm, Pif <fjs...(a)laposte.net> wrote: > We have an internal ERP. I need to modify session management to detect > that a user disconnects and to free his resources. I'd hazard to guess that the sum economic cost of this thread is already greater than than the cost of purchasing hardware to solve the problem on the server end.
From: Stefan Weiss on 7 Apr 2010 22:54 On 08/04/10 03:32, Garrett Smith wrote: > RobG wrote: >> Have you considered a logout button with encouragement for users to >> use it? Since this seems to be an intranet application, users could be >> taught to use it during their training in the application. You could >> use server logs to see which users are timing-out and remind them that >> to save resources, they should be using the logout button before >> navigating away or leaving the application idle. >> > What incentive does the user have to logout? I'm guessing that such > button would not have a big enough impact. The longer session timeout (as RobG suggested) would be one such incentive. My bank does something different to encourage its customers to log out: if you just let your session expire instead of explicitly logging out, you're presented with an info page on your next log-in, and you need to click a "yes, I understand" button to continue with your netbanking session. This does get the users' attention, and I've seen that page a few times myself, because the netbanking sessions have a very short idle time (around 15 minutes or so). -- stefan
From: Sean Kinsey on 8 Apr 2010 03:58 On Apr 8, 3:32 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > RobG wrote: > > On Apr 7, 9:47 pm, Sean Kinsey <okin...(a)gmail.com> wrote: > > [...] > >> A server-side expiration quite similar to the one you explained is the > >> main approach, the popup is only there to allow for a faster reset > >> (not having to wait for the session to expire before being allowed to > >> log in again etc.) > >> And the user has in most cases allowed popups from the application in > >> order to access certain features, so for them it does work. > > > Have you considered a logout button with encouragement for users to > > use it? Since this seems to be an intranet application, users could be > > taught to use it during their training in the application. You could > > use server logs to see which users are timing-out and remind them that > > to save resources, they should be using the logout button before > > navigating away or leaving the application idle. Its not an intranet app, and we do have a signout button, and we do encourage the users to use it. The point here is not to expire the session, but to, if possible expire the session faster than the main approach in cases where it is not used. > > What incentive does the user have to logout? I'm guessing that such > button would not have a big enough impact. > > > Just suggestions, of course. > > Another idea would be to make a req, such as new Image, or XHR, as Lahn > stated, and use that to expire the session on the server. No guarantee > with that, but it would alleviate some server issues. It has already been discussed and this is still not possible to use. It can, and is, used to persist the session, but cannot be used to notify the server about a navigation due to the code not knowing if the navigation is a safe refresh or not. To propose the only way it _could_ work: * In a pre-unload event, run a sync XHR/equivalent that modifies the session to expire in a minute amount like 10 seconds. * If the client does not issue a new request to the server, the session expire normally * If the client issues a new request before expiration, then the regular session expiration extension mechanism kicks in and extends the session. Actually, I might just do the above, sounds like fun! > > The pop up window is clearly not a good idea. > > What you are doing is trying to provide extra code on the client to make > up for a problem on the server. Not really. We have thousands of users, and some of these tend to do stupid things like close the browser etc, does not answer the appropriate answer from the dialog brought up by the onbeforeunload event, and then opens a new browser to sign in again. The 'extra code' on the client took about 30 min to write, and works successfully as long as the popup is allowed. > > Did the experts at your company look into the session object on the > server? Am I going to far to call them experts? Chances are there are > more efficient ways of fulfilling requirements. <childsvoice>session object? whats that?</childsvoice> Does it suffice to answer yes?
From: Antony Scriven on 8 Apr 2010 05:26 On Apr 8, 8:58 am, Sean Kinsey wrote: > [...] > > It has already been discussed and this is still not > possible to use. It can, and is, used to persist the > session, but cannot be used to notify the server about > a navigation due to the code not knowing if the > navigation is a safe refresh or not. > > To propose the only way it _could_ work: > * In a pre-unload event, run a sync XHR/equivalent that > modifies the session to expire in a minute amount like 10 > seconds. > * If the client does not issue a new request to the > server, the session expire normally > * If the client issues a new request before expiration, > then the regular session expiration extension mechanism > kicks in and extends the session. > Actually, I might just do the above, sounds like fun! > > [...] And what if the server requests arrive in an order different from what you expected? --Antony
From: Thomas 'PointedEars' Lahn on 8 Apr 2010 05:37
Sean Kinsey wrote: > To propose the only way it _could_ work: > * In a pre-unload event, run a sync XHR/equivalent that modifies the > session to expire in a minute amount like 10 seconds. > * If the client does not issue a new request to the server, the > session expire normally > * If the client issues a new request before expiration, then the > regular session expiration extension mechanism kicks in and extends > the session. > Actually, I might just do the above, sounds like fun! Idiot. I have proposed that approach yesterday. <news:11375999.mABFhMhkbZ(a)PointedEars.de> PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann |