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

Re: [whatwg] Modifying the URL inside beforeunload event

From: cowwoc <cowwoc@bbs.darktech.org>
Date: Fri, 14 Nov 2014 21:07:18 -0500
Message-ID: <5466B556.9020202@bbs.darktech.org>
To: whatwg@lists.whatwg.org
On 14/11/2014 8:56 PM, Roger Hågensen wrote:
> 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 reply.
> 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 
> http://stackoverflow.com/questions/26556749/binding-tab-specific-data-to-an-http-get-request
> 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).
> Regards,
> Roger.

Hi Roger,

Did you also use a URL parameter to indicate which cookie the server 
should look in? I think my solution is problematic in that I have to go 
through GetTabId.html on page load (which looks ugly) and even worse I 
recently discovered that View Source does not work because the browser 
re-sends the request without the tabId parameter (which I stripped to 
make the URL shareable).

I feel like the ideal solution is within an arm's reach but I can't get 

Please describe your approach in more detail on 
http://stackoverflow.com/q/26556749/14731 so we can learn for each.

Received on Saturday, 15 November 2014 02:07:52 UTC

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