[whatwg] When closing the browser
I made a quick look through the HTML 5 Working Draft table of contents, as well
as Anne's "differences" document and went looking through
http://www.w3.org/html/wg/html5/#processing2 the changes on the network and
processing models to see if this was covered or not, but didn't see it. I
probably missed it, but noticed something today that I was fooling around with
some years ago and wondered if it has been addressed.
The user opens a web application as one of many tabs in a web browser. They
then, either within the application window, accidentally hit CTRL W (or its Mac
equivalent), or from the operating system, issue a close application command.
Most apps (as opposed to the more "passive" browsers) detect that new content
has been developed and in is jeopardy of being lost and therefore prompt the
user to the status of this possible data loss. The browser, unless I'm missing
something, seems to have a different status within the OS and just closes
without ceremony.
The way I've handled this is the past is to have an onunload script associated
with the body: onunload="if (confirm('Save before quitting')) (SaveIt());"
where SaveIt is some magic function which writes to disk (I understand that
such a technique will standardize writing to local drive space in HTML5). I
also understand that there will be ways of overriding the default definitions
of CTRL-W etc. so that the developer may change these unpleasantries inherited
from the browser. However, in the case of the solution using onload/confirm,
(if you're not averse to using IE and looking at VML then see
http://srufaculty.sru.edu/david.dailey/grapher/grapher.96.html for an example)
, you have two choices: save and cancel -- "cancel" terminates without saving,
"save" terminates after saving.
Has this group or HTMLWG yet decided on a way of preventing accidental loss of
work for web applications in a way similar to how "applications" handle the
situation?
cheers,
David
Re: [whatwg] When closing the browser
David,
The onbeforeunload event handler can be used in this manner. See these posts:
http://www.nczonline.net/archive/2006/3/311
http://www.nczonline.net/archive/2006/3/312
-Nicholas
I made a quick look through the HTML 5 Working Draft table of contents, as well
as Anne's "differences" document and went looking through
http://www.w3.org/html/wg/html5/#processing2 the changes on the network and
processing models to see if this was covered or not, but didn't see it. I
probably missed it, but noticed something today that I was fooling around with
some years ago and wondered if it has been addressed.
The user opens a web application as one of many tabs in a web browser. They
then, either within the application window, accidentally hit CTRL W (or its Mac
equivalent), or from the operating system, issue a close application command.
Most apps (as opposed to the more "passive" browsers) detect that new content
has been developed and in is jeopardy of being lost and therefore prompt the
user to the status of this possible data loss. The browser, unless I'm missing
something, seems to have a different status within the OS and just closes
without ceremony.
The way I've handled this is the past is to have an onunload script associated
with the body: onunload="if (confirm('Save before quitting')) (SaveIt());"
where SaveIt is some magic function which writes to disk (I understand that
such a technique will standardize writing to local drive space in HTML5). I
also understand that there will be ways of overriding the default definitions
of CTRL-W etc. so that the developer may change these unpleasantries inherited
from the browser. However, in the case of the solution using onload/confirm,
(if you're not averse to using IE and looking at VML then see
http://srufaculty.sru.edu/david.dailey/grapher/grapher.96.html for an example)
, you have two choices: save and cancel -- "cancel" terminates without saving,
"save" terminates after saving.
Has this group or HTMLWG yet decided on a way of preventing accidental loss of
work for web applications in a way similar to how "applications" handle the
situation?
cheers,
David
Re: [whatwg] When closing the browser
On Thu, 28 Feb 2008, ddailey wrote: > > The user opens a web application as one of many tabs in a web browser. > They then, either within the application window, accidentally hit CTRL W > (or its Mac equivalent), or from the operating system, issue a close > application command. Most apps (as opposed to the more "passive" > browsers) detect that new content has been developed and in is jeopardy > of being lost and therefore prompt the user to the status of this > possible data loss. The browser, unless I'm missing something, seems to > have a different status within the OS and just closes without ceremony. I just went ahead and specced out the 'onbeforeunload' feature that most browsers support today that handles this case. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] When closing the browser
Ian Hickson wrote on 12/12/2008 2:50 AM: > On Thu, 28 Feb 2008, ddailey wrote: >> The user opens a web application as one of many tabs in a web browser. >> They then, either within the application window, accidentally hit CTRL W >> (or its Mac equivalent), or from the operating system, issue a close >> application command. Most apps (as opposed to the more "passive" >> browsers) detect that new content has been developed and in is jeopardy >> of being lost and therefore prompt the user to the status of this >> possible data loss. The browser, unless I'm missing something, seems to >> have a different status within the OS and just closes without ceremony. > > I just went ahead and specced out the 'onbeforeunload' feature that most > browsers support today that handles this case. Speaking of 'onbeforeunload' and 'beforeunload' -- it'd be helpful if there was a way to distinguish between the user taking an action which leaves the site vs. taking an action that returns to the site. E.g.: leaves site: closes browser closes tab closes window back/forward to different site GET/POST to another site navigates away using address bar returns to site: reloads page back/forward to same site GET/POST to same site For privacy, it shouldn't reveal which specific action triggered the event, but knowing if the user is leaving the site means webapps can finally auto-logout the user, which in turn greatly improves security. - Bil
Re: [whatwg] When closing the browser
Bil Corry ha scritto: Speaking of 'onbeforeunload' and 'beforeunload' -- it'd be helpful if there was a way to distinguish between the user taking an action which leaves the site vs. taking an action that returns to the site. E.g.: leaves site: closes browser closes tab closes window back/forward to different site GET/POST to another site navigates away using address bar returns to site: reloads page back/forward to same site GET/POST to same site For privacy, it shouldn't reveal which specific action triggered the event, but knowing if the user is leaving the site means webapps can finally auto-logout the user, which in turn greatly improves security. - Bil That's a nice idea; the before unload event, for instance, might hold a boolean attribute telling whether the user is navigating to the same domain or not. Anyway, such might fail somehow (or sometimes) if (a relevant part of) the webapp were contained in a frame/iframe inside a document coming from a different domain. Actually, I think your proposed behaviour might be worked around with short-living persistent cookies (when enabled, of course). For a login mechanism fully based on (non-http-only) cookies, setting a short-timed expire date (a matter of few seconds) should do the trick: if the user action is directed to the same site, the server would recieve the cookie before its expiration; when loading a page within the login cookie lifetime, the page would change the expiration time accordingly. For a more complex (and secure) login mechanism, a short-living persistent cookie might hold a 'secondary' session-id with an expiration date set, before unloading, so to match a predefined delay: the webapp would issue a delayed logout, so that after the choosen delay every session data would be invalidated, and the user logged-out; if an attacker grabbed such a secondary cookie, he wouldn't get any relevant login information, and its suitability for a cross-site attack (e.g. by loading a page from the target site before the cookie expiration) would be restricted to an arbitrarily short time (such would be a similar strategy to bank token generators: imperfect but working). Otherwise, the user might be prompted for an explicit logout request before unloading (as suggested for volatile data). Perhaps a combination of three methods (the boolean attribute telling about same-domain navigation, a short-living cookie and an explicit choice by the user) might improve the overall security. -- Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f Sponsor: CheBanca! La prima banca che ti d� gli interessi in anticipo. * Fino al 4,70% sul Conto Deposito, zero spese e interessi subito. Aprilo! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8435&d=12-12
Re: [whatwg] When closing the browser
On Fri, 12 Dec 2008, Bil Corry wrote: > > Speaking of 'onbeforeunload' and 'beforeunload' -- it'd be helpful if > there was a way to distinguish between the user taking an action which > leaves the site vs. taking an action that returns to the site. > > For privacy, it shouldn't reveal which specific action triggered the > event, but knowing if the user is leaving the site means webapps can > finally auto-logout the user, which in turn greatly improves security. If the goal is auto-logout, then what you describe wouldn't help, as it would have false-positives (leaving the site when another tab still has the site open) and false-negatives (a crash wouldn't log out the user). Why do session cookies not address this already? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] When closing the browser
Ian Hickson wrote on 12/12/2008 2:34 PM: > If the goal is auto-logout, then what you describe wouldn't help, as it > would have false-positives (leaving the site when another tab still has > the site open) and false-negatives (a crash wouldn't log out the user). Well, more thought needs to go into it. And maybe it isn't practical, I don't know. > Why do session cookies not address this already? They do to some extent. You can choose to make the session life shorter, increasing security but potentially logging the user out before they're ready OR you can choose to make the session life longer, decreasing security but allowing the user more time. What I see banks do is make the session life short and prompt the user to renew their session before it expires. It could be that's the ideal way to handle it. Or maybe it'd be better if non-persistent cookies are removed once the user no longer has an open tab to the site, instead of using a JavaScript-based solution. - Bil
Re: [whatwg] When closing the browser
On Fri, 12 Dec 2008, Bil Corry wrote: > > > > Why do session cookies not address this already? > > They do to some extent. You can choose to make the session life > shorter, increasing security but potentially logging the user out before > they're ready OR you can choose to make the session life longer, > decreasing security but allowing the user more time. I don't mean short cookie times, I mean literally session cookies, that expire at the end of the session. sessionStorage (from HTML5) might also help with this; it's limited to the lifetime of the tab that it was used in. > Or maybe it'd be better if non-persistent cookies are removed once the > user no longer has an open tab to the site, instead of using a > JavaScript-based solution. This could be done now; I recommend bringing this up with browser vendors as a feature request. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] When closing the browser
Ian Hickson wrote on 12/12/2008 5:11 PM: > On Fri, 12 Dec 2008, Bil Corry wrote: >>> Why do session cookies not address this already? >> They do to some extent. You can choose to make the session life >> shorter, increasing security but potentially logging the user out before >> they're ready OR you can choose to make the session life longer, >> decreasing security but allowing the user more time. > > I don't mean short cookie times, I mean literally session cookies, that > expire at the end of the session. But don't they persist until the entire browser is closed? They'd be perfect if they were removed once all tabs/windows to the site were closed. > sessionStorage (from HTML5) might also help with this; it's limited to > the lifetime of the tab that it was used in. That could work too. >> Or maybe it'd be better if non-persistent cookies are removed once the >> user no longer has an open tab to the site, instead of using a >> JavaScript-based solution. > > This could be done now; I recommend bringing this up with browser vendors > as a feature request. Thanks, it may be something to pursue. - Bil
Re: [whatwg] When closing the browser
Ian Hickson wrote: On Fri, 12 Dec 2008, Bil Corry wrote: Or maybe it'd be better if non-persistent cookies are removed once the user no longer has an open tab to the site, instead of using a JavaScript-based solution. This could be done now; I recommend bringing this up with browser vendors as a feature request. I'm not sure this is as easy as it first appears. For example, consider the following case: * I have a single tab on site1 and I have a session cookie with them. * I navigate from a page on site1 to site2 and site2 replaces site1 in my single tab. * I navigate from site2 back to site1. Have I now lost my session cookie? This scenario is particularly important for technologies that use redirects to exchange data between domains, such as OpenID. Many OpenID implementations (for better or worse) use session cookies to retain state while they do the OpenID transaction, which involves redirecting the user away from your site to a URL on the provider's domain. If implemented exactly as stated, the session cookie would presumably be deleted during the OpenID transaction and the original site will break.
Re: [whatwg] When closing the browser
On Fri, 12 Dec 2008, Martin Atkins wrote: > Ian Hickson wrote: > > On Fri, 12 Dec 2008, Bil Corry wrote: > > > > > Or maybe it'd be better if non-persistent cookies are removed once the > > > user no longer has an open tab to the site, instead of using a > > > JavaScript-based solution. > > > > This could be done now; I recommend bringing this up with browser vendors as > > a feature request. > > I'm not sure this is as easy as it first appears. For example, consider the > following case: > > * I have a single tab on site1 and I have a session cookie with them. > * I navigate from a page on site1 to site2 and site2 replaces site1 in my > single tab. > * I navigate from site2 back to site1. > > Have I now lost my session cookie? > > This scenario is particularly important for technologies that use redirects to > exchange data between domains, such as OpenID. > > Many OpenID implementations (for better or worse) use session cookies to > retain state while they do the OpenID transaction, which involves redirecting > the user away from your site to a URL on the provider's domain. If implemented > exactly as stated, the session cookie would presumably be deleted during the > OpenID transaction and the original site will break. If this was implemented like sessionStorage is specified, then the session cookie would only go away once the tab was completely closed, IIRC. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] When closing the browser
Ian Hickson schrieb: On Fri, 12 Dec 2008, Bil Corry wrote: Speaking of 'onbeforeunload' and 'beforeunload' -- it'd be helpful if there was a way to distinguish between the user taking an action which leaves the site vs. taking an action that returns to the site. For privacy, it shouldn't reveal which specific action triggered the event, but knowing if the user is leaving the site means webapps can finally auto-logout the user, which in turn greatly improves security. If the goal is auto-logout, then what you describe wouldn't help, as it would have false-positives (leaving the site when another tab still has the site open) You can solve this easily, just use the same algorithm that SessionStorange uses to determine if the session is closed. In other words, only set this value to true if the user closes the tab/navigates to another domain *and* if there are no other open tabs for this domain. and false-negatives (a crash wouldn't log out the user). I think a responsible server implementation would use this *in addition* to session timeouts, not instead of them. Why do session cookies not address this already? I think there are still scenarios where it would be valuable for the server to know *exactly when* the user logged out. One example would be those "XY is online" badges you see in many internet forums today. Today, those have a margin of error of about 15 to 20 minutes at best. With session cookies, if the client doesn't send more requests, the server after all has to guess if you logged out or if you're just taking your time. So you have to wait for a pretty long timeout period in any case. Even if a 15 minute timeout is not so much of a problem from a user perspective, it's still a lot of memory a (potentially buisy) has to keep around longer than really necessary. You can't simply "force-logout" the user inside onunload either, because of the "false positives" above. I believe, such an onunload parameter could fill this gap. With it, you could simply check, if you're the last open window and if you are issue a "logout" XHR.
Re: [whatwg] When closing the browser
Ian Hickson ha scritto: On Fri, 12 Dec 2008, Bil Corry wrote: Speaking of 'onbeforeunload' and 'beforeunload' -- it'd be helpful if there was a way to distinguish between the user taking an action which leaves the site vs. taking an action that returns to the site. For privacy, it shouldn't reveal which specific action triggered the event, but knowing if the user is leaving the site means webapps can finally auto-logout the user, which in turn greatly improves security. If the goal is auto-logout, then what you describe wouldn't help, as it would have false-positives (leaving the site when another tab still has the site open) As well as any tab-restricted session data, if not aware of other tabs/windows (as Philipp Serafin suggested, whatever is done to make a tab aware of other tabs with the same domain, can be done for an attribute telling wheter the user is leaving a certain domain). and false-negatives (a crash wouldn't log out the user). Which may affect persistent cookies, but can be a concern for any solution, when it comes with cookie theft (that is, some communication with the server may be needed, beside the use of cookies or anything else, and such may fail because of a crash). Why do session cookies not address this already? Both session and persistent cookies may address this (with the concern of false negatives, specially for persistent cookies, but not only). Both need to be enabled in a browser to work (usually they are, session cookies most of times). Both may fail alone (that is, if an immediate invalidation of login data is required - this is a side, related issue). If the goal is auto-logout *as soon as the user leaves the site*, whenever the downside of a possible new login request during the same session is not a usability concern, a (session) cookie lifetime must be shortened, for instance by adding an expiration timing (e.g., for a session cookie, something like 'sessionID=asdf1234fdas.exp=date + 3 seconds>;'), this way if the user reloads the page or navigates a tab history the server will likely recieve such modified cookie before its 'expiration' and abort an atuo-logout process (a cached webapp may check cookies as well), otherwise, whenever recieving an 'expired' cookie, the logout would trigger immediately; if the client-side script knew the user is leaving the site, any cookie might be removed. But such wouldn't solve the server-side logout concern: to invalidate any login data, in the above scenario an expired cookie must be recieved, thus possibly giving a cookie thief a longer time to work. Of course, there are solutions to address that. A first one may consist of telling the server to trigger a delayed logout process, waiting for a cookie before timing out (in this case, there might not be any need to modify cookies, though such might be done as well, e.g. with a random value communicated to the server in order to prevent an attacker from using a stolen cookie - or to mitigate the effectiveness of a cookie theft). Nontheless, such a solution may fail because of a crash, thus a server-side timeout may be preferred (even just setting a date value after which any recieved cookie is no more valid); a more complex scenario may involve both a server timeout, a client-side-triggered logout (for immediate logout), and bidirectional communications (to reset any timeout and eventually to update cookies). The above won't prevent false positives; a further cookie might be used as a counter to be incremented by any loaded page and decreased by any left page, delegating effective logout to the last page (unless a server-side timeout-only solution were preferred, but such wouldn't address the 'immediate auto-logout' goal we started from). All fine, although based on the assumption at least session cookies are avalaible, which is true most of times, and, when false (a privacy-paranoid user?), just telling the user he needs to enable cookies works. However, a kind of "DOM-only" alternative, not bothering the user to change his privacy settings and perhaps a bit easier to handle (script-side) than cookies in some cases, might be appreciable: an attribute telling when the site is about to be left during current session, and cross-windows messaging, with some blessed origin checking, when some cooperation is needed (e.g. to tell a widget inside an iframe to keep logged in, or to share a secret ID with pages from the same domain). Best regards, Alex. -- Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f Sponsor: CheBanca! La prima banca che ti dà gli interessi in anticipo. * Fino al 4,70% sul Conto Deposito, zero spese e interessi subito. Aprilo! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7918&d=13-12
Re: [whatwg] When closing the browser
On Sat, 13 Dec 2008, Philipp Serafin wrote: > Ian Hickson schrieb: > > On Fri, 12 Dec 2008, Bil Corry wrote: > > > > > Speaking of 'onbeforeunload' and 'beforeunload' -- it'd be helpful > > > if there was a way to distinguish between the user taking an action > > > which leaves the site vs. taking an action that returns to the site. > > > > > > For privacy, it shouldn't reveal which specific action triggered the > > > event, but knowing if the user is leaving the site means webapps can > > > finally auto-logout the user, which in turn greatly improves > > > security. > > > > If the goal is auto-logout, then what you describe wouldn't help, as > > it would have false-positives (leaving the site when another tab still > > has the site open) > > You can solve this easily, just use the same algorithm that > SessionStorange uses to determine if the session is closed. In other > words, only set this value to true if the user closes the tab/navigates > to another domain *and* if there are no other open tabs for this domain. SessionStorage doesn't ever close the session explicitly (though it commonly gets into situations where it can never be reached again, at which point the browser can "reap" it). However, even if it did, that doesn't work -- there could well be other sessions (other windows entirely) that are logged into the same site. > > and false-negatives (a crash wouldn't log out the user). > > I think a responsible server implementation would use this *in addition* > to session timeouts, not instead of them. I think if we have as a use case making something that provides a better logout solution, it should fix the actual use case significantly better than existing solutions. > > Why do session cookies not address this already? > > I think there are still scenarios where it would be valuable for the > server to know *exactly when* the user logged out. One example would be > those "XY is online" badges you see in many internet forums today. > Today, those have a margin of error of about 15 to 20 minutes at best. In my own experience, closing the page is not a good indicator of when I've "logged out". I often have tabs open that I'm not planning on returning to, and I often close tabs only to reopen them shortly after. I see the same behaviour with others. So it's not clear to me that this would really improve matters. > With session cookies, if the client doesn't send more requests, the > server after all has to guess if you logged out or if you're just taking > your time. So you have to wait for a pretty long timeout period in any > case. Even if a 15 minute timeout is not so much of a problem from a > user perspective, it's still a lot of memory a (potentially buisy) has > to keep around longer than really necessary. It's not clear to me why keeping a user logged in should take significant memory, but maybe I don't understand the use case well enough. Could you elaborate? For most sites, a user would just be a row in a database, surely. > You can't simply "force-logout" the user inside onunload either, because > of the "false positives" above. Depending on the situation, maybe a better solution would be for a shared worker to have a WebSocket connection to the server, and for the server to take the closing of the WebSocket connection as a logout. This addresses all the concerns like multiple tabs, timeouts, crashes, etc. On Sat, 13 Dec 2008, Calogero Alex Baldacchino wrote: > > If the goal is auto-logout *as soon as the user leaves the site*, > whenever the downside of a possible new login request during the same > session is not a usability concern, a (session) cookie lifetime must be > shortened, for instance by adding an expiration timing (e.g., for a > session cookie, something like 'sessionID=asdf1234fdas.exp= date + 3 seconds>;'), this way if the user reloads the page or navigates > a tab history the server will likely recieve such modified cookie before > its 'expiration' and abort an atuo-logout process (a cached webapp may > check cookies as well), otherwise, whenever recieving an 'expired' > cookie, the logout would trigger immediately; if the client-side script > knew the user is leaving the site, any cookie might be removed. This seems like the better short-term solution, yes. > But such wouldn't solve the server-side logout concern: to invalidate > any login data, in the above scenario an expired cookie must be > recieved, thus possibly giving a cookie thief a longer time to work. Of > course, there are solutions to address that. If there is a security concern, please use real encryption! -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] When closing the browser
Ian Hickson wrote on 4/24/2009 6:36 PM: >>> Why do session cookies not address this already? >> I think there are still scenarios where it would be valuable for the >> server to know *exactly when* the user logged out. One example would be >> those "XY is online" badges you see in many internet forums today. >> Today, those have a margin of error of about 15 to 20 minutes at best. > > In my own experience, closing the page is not a good indicator of when > I've "logged out". I often have tabs open that I'm not planning on > returning to, and I often close tabs only to reopen them shortly after. I > see the same behaviour with others. So it's not clear to me that this > would really improve matters. I think it's important to note that some web applications may choose to constrain users more tightly to improve security (such as when forcing the user to choose a stronger password than they would normally choose). So while you may not consider leaving the page as "logging out," your bank may choose to interpret it differently, especially if they determine that most of their users never use the "log out" feature on the site. - Bil
Re: [whatwg] When closing the browser
On Mon, 27 Apr 2009, Bil Corry wrote: > Ian Hickson wrote on 4/24/2009 6:36 PM: > >>> > >>> Why do session cookies not address this already? > >> > >> I think there are still scenarios where it would be valuable for the > >> server to know *exactly when* the user logged out. One example would > >> be those "XY is online" badges you see in many internet forums today. > >> Today, those have a margin of error of about 15 to 20 minutes at > >> best. > > > > In my own experience, closing the page is not a good indicator of when > > I've "logged out". I often have tabs open that I'm not planning on > > returning to, and I often close tabs only to reopen them shortly > > after. I see the same behaviour with others. So it's not clear to me > > that this would really improve matters. > > I think it's important to note that some web applications may choose to > constrain users more tightly to improve security (such as when forcing > the user to choose a stronger password than they would normally choose). > So while you may not consider leaving the page as "logging out," your > bank may choose to interpret it differently, especially if they > determine that most of their users never use the "log out" feature on > the site. True... One option would be to have an attribute, say , which causes the user agent to ping the site when the window is closed and there are no other windows open to the same origin. Of course this would break if the other window in question was open to a different page that didn't have the logout="" attribute.. Maybe it should be invoked if there are no other pages open that have the same logout="" attribute? This has the advantage of not depending on JavaScript, and not affecting the browser's performance (no waiting for sync XHR, etc). It would work somewhat like PING does today, though probably using POST. Opinions? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] When closing the browser
On Mon, Apr 27, 2009 at 1:24 PM, Ian Hickson wrote: > One option would be to have an attribute, say , which > causes the user agent to ping the site when the window is closed and there > are no other windows open to the same origin. > > Of course this would break if the other window in question was open to a > different page that didn't have the logout="" attribute.. > > Maybe it should be invoked if there are no other pages open that have the > same logout="" attribute? > > This has the advantage of not depending on JavaScript, and not affecting > the browser's performance (no waiting for sync XHR, etc). > > It would work somewhat like PING does today, though probably using POST. As an author, I'd definitely use it. I'd want the second option (ping when you close the last window with a given logout attribute), as that would allow me to define 'domains' within the same origin that track logins separately. It would be easy to code against the lack of this (just do an occasional cleanup of sessions that have aged too much, which you'd have to do anyway in case of nonstandard browser exits), but would allow better, more reliable security for users with browsers that implement it. Trying to handle this through javascript onunload is nontrivial currently, but @logout would make it both trivial and dependable. ~TJ
Re: [whatwg] When closing the browser
Ian Hickson schrieb: > One option would be to have an attribute, say , Maybe is more suitable? > which > causes the user agent to ping the site when the window is closed and there > are no other windows open to the same origin. > > Of course this would break if the other window in question was open to a > different page that didn't have the logout="" attribute.. > > Maybe it should be invoked if there are no other pages open that have the > same logout="" attribute? Sounds ok to me. Server-side applications should probably implement that in a way such that just one session (identified by a session cookie or whatever) gets logged out -- in contrast to all sessions of a user. The user might be logged in using 2 different browsers and might want to log out in one browser but keep the session active in the second one. And I'd probably want a same domain policy for the logout ping be implemented in the browser. -- Philipp Kempgen
Re: [whatwg] When closing the browser
Ian Hickson wrote on 4/27/2009 1:24 PM: > One option would be to have an attribute, say , which > causes the user agent to ping the site when the window is closed and there > are no other windows open to the same origin. > > Of course this would break if the other window in question was open to a > different page that didn't have the logout="" attribute.. > > Maybe it should be invoked if there are no other pages open that have the > same logout="" attribute? > > This has the advantage of not depending on JavaScript, and not affecting > the browser's performance (no waiting for sync XHR, etc). > > It would work somewhat like PING does today, though probably using POST. I like the idea -- thinking out loud here, rather than invoking it when all pages having the same logout="" attribute are closed, can it instead use some other grouping identifier? That would allow a developer to pass back unique information from each page via the URI. And I like POST instead of GET. A same-origin restriction would be good too. Would the browser accept a response from the logout? I'm thinking that could be used to immediate end the cookie(s). - Bil
Re: [whatwg] When closing the browser
On Mon, 27 Apr 2009, Tab Atkins Jr. wrote: > On Mon, Apr 27, 2009 at 1:24 PM, Ian Hickson wrote: > > One option would be to have an attribute, say , which > > causes the user agent to ping the site when the window is closed and there > > are no other windows open to the same origin. > > > > Of course this would break if the other window in question was open to a > > different page that didn't have the logout="" attribute.. > > > > Maybe it should be invoked if there are no other pages open that have the > > same logout="" attribute? > > > > This has the advantage of not depending on JavaScript, and not affecting > > the browser's performance (no waiting for sync XHR, etc). > > > > It would work somewhat like PING does today, though probably using POST. > > As an author, I'd definitely use it. I'd want the second option (ping > when you close the last window with a given logout attribute), as that > would allow me to define 'domains' within the same origin that track > logins separately. > > It would be easy to code against the lack of this (just do an occasional > cleanup of sessions that have aged too much, which you'd have to do > anyway in case of nonstandard browser exits), but would allow better, > more reliable security for users with browsers that implement it. > > Trying to handle this through javascript onunload is nontrivial > currently, but @logout would make it both trivial and dependable. On Mon, 27 Apr 2009, Jo�o Eiras wrote: > > What if there is a loss of connectivity or the user agent crashes ? > Relying on user agent telling when documents are unloaded has never been > reliable nor will ever be. So, websites do timeouts and will continue to > do so because those are needed. > > This is really about making the whole logout process more friendly for > the web developer though. I thought of exporting a service, using a > special element or something, which the user agent could call when if > unloads all documents related to that origin or a special token in that > element. Like > > The user agent would do a GET request of /logout when it no longer had > documents loaded on windows with a logout tag with that specific > specialtoken value. specialtoken (or whaever you'd like to call it) > could be optional and in that case the user agent could rely on origin. > > This way, the server would not need to count the number of loaded > documents. On Mon, 27 Apr 2009, Philipp Kempgen wrote: > > Maybe is more suitable? > > Server-side applications should probably implement that in a way such > that just one session (identified by a session cookie or whatever) gets > logged out -- in contrast to all sessions of a user. The user might be > logged in using 2 different browsers and might want to log out in one > browser but keep the session active in the second one. > > And I'd probably want a same domain policy for the logout ping be > implemented in the browser. On Tue, 28 Apr 2009, Bil Corry wrote: > > I like the idea -- thinking out loud here, rather than invoking it when > all pages having the same logout="" attribute are closed, can it instead > use some other grouping identifier? That would allow a developer to > pass back unique information from each page via the URI. And I like > POST instead of GET. A same-origin restriction would be good too. > Would the browser accept a response from the logout? I'm thinking that > could be used to immediate end the cookie(s). I like Philipp's idea of making this a new "rel" value. I encourage people who are interested in this idea to add it to the WHATWG RelExtensions wiki, write a spec for it (you can put it on a page on that wiki if you like) and then see if browser vendors are interested in supporting this feature. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] When closing the browser
I'm joining the thread late, so apologies if I'm missing the point, but for me it would be very useful to have better session management facilities -- like those available in Qt, for example, or at least something analogous to the Cocoa Touch applicationWillTerminate: method. Sam Dutton http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.
Re: [whatwg] When closing the browser
Ian Hickson wrote on 6/4/2009 7:02 PM: > On Mon, 27 Apr 2009, Tab Atkins Jr. wrote: >> On Mon, Apr 27, 2009 at 1:24 PM, Ian Hickson wrote: >>> One option would be to have an attribute, say , which >>> causes the user agent to ping the site when the window is closed and there >>> are no other windows open to the same origin. >>> >>> Of course this would break if the other window in question was open to a >>> different page that didn't have the logout="" attribute.. >>> >>> Maybe it should be invoked if there are no other pages open that have the >>> same logout="" attribute? >>> >>> This has the advantage of not depending on JavaScript, and not affecting >>> the browser's performance (no waiting for sync XHR, etc). >>> >>> It would work somewhat like PING does today, though probably using POST. >> As an author, I'd definitely use it. I'd want the second option (ping >> when you close the last window with a given logout attribute), as that >> would allow me to define 'domains' within the same origin that track >> logins separately. >> >> It would be easy to code against the lack of this (just do an occasional >> cleanup of sessions that have aged too much, which you'd have to do >> anyway in case of nonstandard browser exits), but would allow better, >> more reliable security for users with browsers that implement it. >> >> Trying to handle this through javascript onunload is nontrivial >> currently, but @logout would make it both trivial and dependable. > > On Mon, 27 Apr 2009, Jo�o Eiras wrote: >> What if there is a loss of connectivity or the user agent crashes ? >> Relying on user agent telling when documents are unloaded has never been >> reliable nor will ever be. So, websites do timeouts and will continue to >> do so because those are needed. >> >> This is really about making the whole logout process more friendly for >> the web developer though. I thought of exporting a service, using a >> special element or something, which the user agent could call when if >> unloads all documents related to that origin or a special token in that >> element. Like >> >> The user agent would do a GET request of /logout when it no longer had >> documents loaded on windows with a logout tag with that specific >> specialtoken value. specialtoken (or whaever you'd like to call it) >> could be optional and in that case the user agent could rely on origin. >> >> This way, the server would not need to count the number of loaded >> documents. > > On Mon, 27 Apr 2009, Philipp Kempgen wrote: >> Maybe is more suitable? >> >> Server-side applications should probably implement that in a way such >> that just one session (identified by a session cookie or whatever) gets >> logged out -- in contrast to all sessions of a user. The user might be >> logged in using 2 different browsers and might want to log out in one >> browser but keep the session active in the second one. >> >> And I'd probably want a same domain policy for the logout ping be >> implemented in the browser. > > On Tue, 28 Apr 2009, Bil Corry wrote: >> I like the idea -- thinking out loud here, rather than invoking it when >> all pages having the same logout="" attribute are closed, can it instead >> use some other grouping identifier? That would allow a developer to >> pass back unique information from each page via the URI. And I like >> POST instead of GET. A same-origin restriction would be good too. >> Would the browser accept a response from the logout? I'm thinking that >> could be used to immediate end the cookie(s). > > I like Philipp's idea of making this a new "rel" value. I encourage people > who are interested in this idea to add it to the WHATWG RelExtensions > wiki, write a spec for it (you can put it on a page on that wiki if you > like) and then see if browser vendors are interested in supporting this > feature. I've added a quick first draft to the wiki: http://wiki.whatwg.org/wiki/RelExtensions http://wiki.whatwg.org/wiki/LogoutRelExtension I don't know the correct vernacular for these types of documents, so if it should be URL instead of URI, etc, then feel free to edit the wiki directly. - Bil
