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
