Making session storage play nicely with server side sessions

Session and local storage have made the storage of data on a clients machine respectable, gone are the big cookies and window.name, partnered with the ability to define manifest files developers can now exert control over how resources and data are cached to a level that makes Apache and IIS look embarrassing.

However, with every new feature, some things get easier and some things get harder.

Session storage is held only in a particular tab or window, allocated to the domain and lasting as long as that window persists. Opening the same domain in another tab will create a new session. Local storage is also allocated to a domain but persists between sessions, tabs and windows.

Web storage does not cater for different users, domains and windows are all it knows.

There are additional complications if users on your site are able to login, if your web storage includes data individual to the user you need to take care to clear and refresh data whenever the state changes

How to maintain state between web storage and server sessions

It might be a bit old-school, but Cookies are still the way that most back-end systems track user sessions. The simplest thing to do is to store the value of the session cookie in your web storage and to compare those values when the page loads and if the values differ clear the session of user specific data.

	sLocalKey = 'StoredIdentity',
	sCookieKey = 'CookieKey',
	storedIdent = window.localStorage.getItem(sLocalKey);
	sCookieValue = readCookie(CookieKey);

	if (sCookieValue === storedIdent) {
		return true; //same cookie value
	}
	else {
		return sCookieValue; //different value, new session
	}

Another case to watch for is a login/logout events, it's unlikely the cookie value will change (the session existed before login) but either you can watch for a query-string value or particular pages like login/logout success.

"The Web Behind the Medium" - An article for the Idea Engineers Blog

Over the past few months I've been amazed at how simple it can be to reuse the same code and structures on quite different devices. When I was asked to write an article for Sapient's Idea Engineer blog I straight away knew that was what I wanted to talk about.

The purpose of the article is to highlight the idea that using the technology of the web (APIs, JavaScript, CSS) can save us time and effort when developing for multiple, disparate platforms.

Read The Web Behind the Medium (Idea Engineers)

Hashbangs, useful, but probably not what you want

In the modern web AJAX is the workhorse behind the interactions. CSS3 might add the shine but AJAX is still doing the work. The strength of AJAX is that it's a background request, the UI will ignore them completely, which is fantastic unless you've just ripped out the hole page content and replaced it with another one.

To enable the user to track that changed state you need to change the URL, and this is where hashbangs come in. Hashbangs are a work-around. But Hashbangs are an old workaround for an old problem.

Where previously we only has window.location available to us we now have the history API, window.history.

Use pushState to add states and watch for the popstate event to revert to previous states.

One final caveat, if you are updating only a region of your page then a hashbang may still be valid for you. The hashbang URL must convert into a querystring URL for search engines to parse the content. They expect only the changed content to be returned when they visit that converted URL.

Resources