[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=<current gmt 
> 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.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 24 April 2009 16:36:56 UTC