W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2014

Re: [whatwg] Modifying the URL inside beforeunload event

From: Roger Hågensen <rescator@emsai.net>
Date: Sat, 15 Nov 2014 02:56:49 +0100
Message-ID: <5466B2E1.7060405@emsai.net>
To: whatwg@lists.whatwg.org
On 2014-11-15 02:08, cowwoc wrote:
>> Personally the way I build apps these days is to just serve static 
>> files over HTTP, and do all the dynamic stuff over WebSocket, which 
>> would sidestep all these issues.
> You mean you have a single-paged application and rewrite the 
> underlying page asynchronously? How do you deal with needing to load 
> different Javascript files per page? I guess you could simply load all 
> the JS files all your pages would ever need, but I assume you do 
> something a little more sophisticated.
> Thanks,
> Gili

The way you did it was with what I call a "one shot cookie". A project I 
worked on I did a solution where sessionStorage was used to keep a token 
and a cookie was set via javascript and thus sent along with the request 
to the server which then tells the browser to delete the cookie in the 
If the token needs updating then the server can send a "one shot cookie" 
to the browser, the javascript will then apply the needed changes to 
generate a new token (maybe a new salt or nonce is given) and then 
delete the cookie.
Also, this form of cookie use does not fall under the "cookie law" in 
Europe AFAIK as it's part of a login mechanism so no need to show those 
annoying "this site/page uses cookies" box or warning.

Using sessionStorage, and cookies to pass info to/from the server is my 
new preferred way as you can control how often the cookies are sent and 
to what part of the site.

The solution is not as elegant as I'd like it though. One issue is you 
can't set the timeout for a cookie (sent from the server) to 0 or 1 sec 
or similar as the browser could delete the cookie before your javascript 
can get the data from it.
In the other direction the issue is reliably deleting the cookie after 
it has been sent (sometimes one can use POST requests and avoid this 
part, but that may not always be practical).

Looking at 
the solution you ended up with is very similar to what I ended up doing, 
I'm not aware of any better way to do this (yet).


Roger "Rescator" Hågensen.
Freelancer - http://www.EmSai.net/
Received on Saturday, 15 November 2014 01:57:17 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:26 UTC