6

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.

Community
  • 1
  • 1
ripper234
  • 222,824
  • 274
  • 634
  • 905
  • 3
    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. – Per Salbark Jun 20 '12 at 14:30
  • Related: [Is there any workaround to make use of html5 localstorage on both http and https?](http://stackoverflow.com/q/10502469?is-there-any-workaround-to-make-use-of-html5-localstorage-on-both-http-and-https). The accepted answer uses an iframe + `postMessage`. – Rob W Jun 20 '12 at 14:30
  • @RobW - interesting. It might be the solution, although it sounds a bit complicated. – ripper234 Jun 20 '12 at 14:33
  • @PerSalbark - let's say blog.site.com and site.com, and maybe search.site.com – ripper234 Jun 20 '12 at 14:33
  • @ripper234 It's not as complicated as it seems. Support is based on support of [`localStorage`](http://caniuse.com/#feat=namevalue-storage) and [`postMessage`](http://caniuse.com/#feat=x-doc-messaging). 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. – Rob W Jun 20 '12 at 15:12
  • @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. – ripper234 Jun 20 '12 at 15:55
  • @ripper234 I've created a demo (and in the progress, fixed some significant errors :p). I hardly notice a difference in speed: http://jsfiddle.net/gK7ce/4/ (hit the Test button). – Rob W Jun 20 '12 at 17:03
  • 1
    @ripper234 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. – BrianFreud Jun 25 '12 at 05:15
  • 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.) – BrianFreud Jun 25 '12 at 05:18

1 Answers1

3

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

Community
  • 1
  • 1
Phillip Berger
  • 2,317
  • 1
  • 11
  • 30