detect exiting the website
in [JavaScript]
|
From: Thomas 'PointedEars' Lahn on 7 Apr 2010 06:26 Sean Kinsey wrote: > Pif wrote: >> We have an internal ERP. I need to modify session management to detect >> that a user disconnects and to free his resources. So, I would like to >> create following behaviour : >> - modal window on close to nothing >> - std window on close open dialog to suggest disconnection > > This is an approach that I use: > On onunload, open up a small window with window.open which contains a > script that waits a short duration and then attemts to access > window.opener.document. > If this succeeds then the document contained in the window is in the > same domain, and you can check the url. If it fails (try/catch) then > it has been navigated outside the domain. > Do the appropriate action and close the window. I presume that opening a window onunload will already fail in the majority of cases nowadays because of built-in popup blockers that are enabled by default. Even if the popup is not blocked, there is a race condition with the access to `window.opener.document', and a dependency on try-catch, in particular relying on that a catchable exception will be thrown at all. I must strongly recommend against this approach. The proper approach, of course, is to let the server-side session expire on inactivity, whereas as long as the ERP application is displayed the server can optionally be pinged in the background via HTTP requests in regular intervals that are shorter than the expiration interval, and to let the server-side session expire explicitly on logout. It has been done before. PointedEars -- Use any version of Microsoft Frontpage to create your site. (This won't prevent people from viewing your source, but no one will want to steal it.) -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
From: Sean Kinsey on 7 Apr 2010 07:47 On Apr 7, 12:26 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > Sean Kinsey wrote: > > Pif wrote: > >> We have an internal ERP. I need to modify session management to detect > >> that a user disconnects and to free his resources. So, I would like to > >> create following behaviour : > >> - modal window on close to nothing > >> - std window on close open dialog to suggest disconnection > > > This is an approach that I use: > > On onunload, open up a small window with window.open which contains a > > script that waits a short duration and then attemts to access > > window.opener.document. > > If this succeeds then the document contained in the window is in the > > same domain, and you can check the url. If it fails (try/catch) then > > it has been navigated outside the domain. > > Do the appropriate action and close the window. > > I presume that opening a window onunload will already fail in the majority > of cases nowadays because of built-in popup blockers that are enabled by > default. Even if the popup is not blocked, there is a race condition with > the access to `window.opener.document', and a dependency on try-catch, in > particular relying on that a catchable exception will be thrown at all. > > I must strongly recommend against this approach. > > The proper approach, of course, is to let the server-side session expire on > inactivity, whereas as long as the ERP application is displayed the server > can optionally be pinged in the background via HTTP requests in regular > intervals that are shorter than the expiration interval, and to let the > server-side session expire explicitly on logout. It has been done before. > > PointedEars > -- > Use any version of Microsoft Frontpage to create your site. > (This won't prevent people from viewing your source, but no one > will want to steal it.) > -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.) 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. Why would you say that there is a race condition?
From: Thomas 'PointedEars' Lahn on 7 Apr 2010 13:19 Sean Kinsey wrote: > Thomas 'PointedEars' Lahn wrote: >> Sean Kinsey wrote: >> > This is an approach that I use: >> > On onunload, open up a small window with window.open which contains a >> > script that waits a short duration and then attemts to access >> > window.opener.document. >> > If this succeeds then the document contained in the window is in the >> > same domain, and you can check the url. If it fails (try/catch) then >> > it has been navigated outside the domain. >> > Do the appropriate action and close the window. >> >> I presume that opening a window onunload will already fail in the >> majority of cases nowadays because of built-in popup blockers that are >> enabled by default. Even if the popup is not blocked, there is a race >> condition with the access to `window.opener.document', and a dependency >> on try-catch, in particular relying on that a catchable exception will >> be thrown at all. >> >> I must strongly recommend against this approach. >> >> The proper approach, of course, is to let the server-side session expire >> on inactivity, whereas as long as the ERP application is displayed the >> server can optionally be pinged in the background via HTTP requests in >> regular intervals that are shorter than the expiration interval, and to >> let the server-side session expire explicitly on logout. It has been >> done before. > > A server-side expiration quite similar to the one you explained is the > main approach, Not at all. > 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.) You can and SHOULD do that without the popup. > And the user has in most cases allowed popups from the application in > order to access certain features, so for them it does work. The application should avoid popup windows to begin with. For one, they are a resource killer and a hindrance to usability. > Why would you say that there is a race condition? You know neither when the popup has finished loading (the opener can be faster than the popup code), nor do you know when the new document is displayed in the opener or when the `document' property of the opener will be available for the read access to fail reliably enough (the popup code can be faster than the opener). Please trim your quotes to the relevant minimum <http://jibbering.com/faq/#posting> pp. PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann
From: Sean Kinsey on 7 Apr 2010 15:16 On Apr 7, 7:19 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > Sean Kinsey wrote: > > Thomas 'PointedEars' Lahn wrote: <snip> > >> The proper approach, of course, is to let the server-side session expire > >> on inactivity, whereas as long as the ERP application is displayed the > >> server can optionally be pinged in the background via HTTP requests in > >> regular intervals that are shorter than the expiration interval, and to > >> let the server-side session expire explicitly on logout. It has been > >> done before. > > > A server-side expiration quite similar to the one you explained is the > > main approach, > > Not at all. Since when did you gain detailed information about our application architecture? > > > 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.) > > You can and SHOULD do that without the popup. So how do you propose to inform the server immediately about a client navigating/closing the window then? I'm really looking forward to you answer here. > > > And the user has in most cases allowed popups from the application in > > order to access certain features, so for them it does work. > > The application should avoid popup windows to begin with. For one, they > are a resource killer and a hindrance to usability. Seriously, you have no knowledge of the application mentioned, so to come with such generalized statements are just silly. But hey, thats pretty much all to expect around here.. If its a requirement to not navigate the main window AND to open a secondary window/frame then this is not possible without window.open. Or maybe once again you have some secret trick up you sleeve? > > > Why would you say that there is a race condition? > > You know neither when the popup has finished loading (the opener can be > faster than the popup code) who cares about this as the code is hosted IN the popup? It will run when it loads.., , nor do you know when the new document is > displayed in the opener or when the `document' property of the opener will > be available for the read access to fail reliably enough (the popup code > can be faster than the opener). again, you know nothing of the application so stop generalizing. The code uses a delay to give ample time load. If its a document on the same domain then I know it will need little time(single document app, so it's always a refresh) (and don't start with dropped connections and all that nonsense), the read will succeed and the popup does nothing. If it doesn't load fast enough and the read fails due to that, or if it fails due to SOP then I perform an action.
From: Thomas 'PointedEars' Lahn on 7 Apr 2010 16:20
Sean Kinsey wrote: > Thomas 'PointedEars' Lahn wrote: >> Sean Kinsey wrote: >> > Thomas 'PointedEars' Lahn wrote: >> >> The proper approach, of course, is to let the server-side session >> >> expire on inactivity, whereas as long as the ERP application is >> >> displayed the server can optionally be pinged in the background via >> >> HTTP requests in regular intervals that are shorter than the >> >> expiration interval, and to let the server-side session expire >> >> explicitly on logout. It has been done before. >> > A server-side expiration quite similar to the one you explained is the >> > main approach, >> Not at all. > > Since when did you gain detailed information about our application > architecture? That is a stupid question. Your application architecture has nothing to do with the fact that the server-side solution that I have suggested has nothing to do with the client-side solution that you have suggested. >> > 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.) >> You can and SHOULD do that without the popup. > > So how do you propose to inform the server immediately about a client > navigating/closing the window then? > I'm really looking forward to you answer here. See below. >> > And the user has in most cases allowed popups from the application in >> > order to access certain features, so for them it does work. >> >> The application should avoid popup windows to begin with. For one, they >> are a resource killer and a hindrance to usability. > > Seriously, you have no knowledge of the application mentioned, It is not necessary to know the application for this statement to be true. > so to come with such generalized statements are just silly. It is not silly, it is a fact. And if you knew a first thing about the Web, you would know this. > But hey, thats pretty much all to expect around here.. > If its a requirement to not navigate the main window AND to open a > secondary window/frame then this is not possible without window.open. Yes, it is. > Or maybe once again you have some secret trick up you sleeve? Use e.g. an Image instance, a frame or iframe or XHR. The odds are better that any of this works because it does not require the creation of a new viewport beforehand, especially not a popup window. >> > Why would you say that there is a race condition? >> You know neither when the popup has finished loading (the opener can be >> faster than the popup code) > > who cares about this as the code is hosted IN the popup? It will run > when it loads.., When it may be either too early or too late. You are either assuming that the browsers must wait for the popup to be fully loaded before navigating away, or that the browser must navigate away first and then open the popup. Both assumptions are wrong. >> , nor do you know when the new document is displayed in the opener or >> when the `document' property of the opener will be available for the >> read access to fail reliably enough (the popup code can be faster than >> the opener). > > again, you know nothing of the application so stop generalizing. > The code uses a delay to give ample time load. "Ample time"? You know *nothing* about the user's environment, their connection properties, and the response time of the server hosting the other Web site that is navigated to. > If its a document on the same domain then I know it will need little > time(single document app, so it's always a refresh) (and don't start > with dropped connections and all that nonsense), It is not nonsense, it is a fact that you cannot reliably determine that way if and when the user has navigated away from the Web site. <http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing> > the read will succeed and the popup does nothing. Wishful thinking. > If it doesn't load fast enough and the read fails due to that, or if it > fails due to SOP then I perform an action. You are ignoring the distinct possibility that accessing the property can fail for another reason, in which case you would still "perform an action" (or so you can hope, assuming try-catch support and a catchable exception), much to the user's disadvantage. PointedEars -- Danny Goodman's books are out of date and teach practices that are positively harmful for cross-browser scripting. -- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004) |