- From: cowwoc <cowwoc@bbs.darktech.org>
- Date: Fri, 14 Nov 2014 21:07:18 -0500
- 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 there. Please describe your approach in more detail on http://stackoverflow.com/q/26556749/14731 so we can learn for each. Thanks, Gili
Received on Saturday, 15 November 2014 02:07:52 UTC