- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 5 Jun 2009 00:02:05 +0000 (UTC)
On Mon, 27 Apr 2009, Tab Atkins Jr. wrote: > On Mon, Apr 27, 2009 at 1:24 PM, Ian Hickson <ian at hixie.ch> wrote: > > One option would be to have an attribute, say <body logout="">, 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 <logout specialtoken="123abcsessionid" content="/logout"> > > 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 <link rel="logout" href="..."> 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. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 4 June 2009 17:02:05 UTC