[whatwg] When closing the browser
Calogero Alex Baldacchino
alex.baldacchino at email.it
Sat Dec 13 09:31:36 PST 2008
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
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=<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.
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).
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
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
More information about the whatwg