Is there a modern sessionStorage alternative that works across subdomains?

Question

We recently switched from cookies to using sessionStorage - the trigger for switching was IE issues.

Now, we're discovering that sessionStorage doesn't work across sub-domains - the storage of www.site.com is isolated from that of site.com.

Is there a modern alternative to get the two to cooperate? This is easily accomplished by cookies, but I'd hate to revert from sessionStorage, or (gasp) use both methods concurrently.

Cesium

Why are you using both ww.site.com and site.com? That's bad in all kinds of ways. Most sites just redirect any calls to www.site.com to site.com. EDIT: Actually, looking at your reputation I guess you already knew that and have a valid reason. – Sleety

Related: Is there any workaround to make use of html5 localstorage on both http and https?. The accepted answer uses an iframe + postMessage. – Giesser

@RobW - interesting. It might be the solution, although it sounds a bit complicated. – Cesium

@PerSalbark - let's say blog.site.com and site.com, and maybe search.site.com – Cesium

@Cesium It's not as complicated as it seems. Support is based on support of localStorage and postMessage. I've updated the answer with a full sample code for getting/setting/removing data across domains you own. The only possible drawback could be that the storage is unavailable until the frame is loaded. – Giesser

@RobW - it's the synchronization issues that bother me. I have found no way to send data using postMessage that would work regardless of whether the parent or the iframe were loaded first. I haven't looked into this too deeply, I admit, so it might be possible. – Cesium

@Cesium I've created a demo (and in the progress, fixed some significant errors :p). I hardly notice a difference in speed: jsfiddle.net/gK7ce/4 (hit the Test button). – Giesser

@Cesium I've recently worked around similar problems. I made it work this way: have the current value of the localStorage (aka lS) item cached. Then watch for a "storage" event - triggered on any page on that lS domain except the one which set the item in lS. Then check the triggering storage event's event.key is the lS one you care about, and compare event.newValue against the cached value. In this way, I managed to get it such that I don't care how many pages are open, or which ones set the value, or in what order. – Lyonnesse

You can even use it to persist a value in lS. I've got an array stringified in there. Just get the new item stored in the array (event.newValue), then write the cached value back to localStorage. (And make sure that in the earlier bit you're checking that the cached value !== the event.newValue, so all the other pages don't get stuck in a loop when you reset the value in lS, and thus trigger yet another storage event.) – Lyonnesse

Answer 1

This is almost a hack, and its not secure but it's a neat trick never the less. JavaScript object window.name can hold strings of data and the data does persist even when loading a new page or switching domains. Check this SO about it here:

Using window.name as a local data cache in web browsers

Impermanent