I would like a method of storing information on the client that can be accessed by both the SSL and nonSSL version of my site. localStorage is a great mechanism but it can only
The way I did this was to use an iframe that does a postMessage to its parent. The iframe is always on https but the parent can be either http or https. This solution assumes the modifications are on SSL only to the storage and syncs it back for non SSL but you could adapt this to send modifications both ways so the non ssl parent sends changes down to the ssl child.
ssl iframe source (storage-sync.html):
if (sessionStorage.cart)
try {
var obj = { cart: JSON.parse(sessionStorage.cart) };
parent.postMessage(JSON.stringify(obj), 'http://yourdomain.com');
} catch(ex) {
console.log(ex);
}
ssl/non ssl parent source:
window.addEventListener('message', function(ev) {
if (ev.origin !== 'https://yourdomain.com')
return;
try {
var obj = JSON.parse(ev.data);
sessionStorage.cart = JSON.stringify(obj.cart);
cart.reload();
} catch(ex) {};
});
$('body').append('<iframe style="display:none" src="https://yourdomain.com/storage-sync.html?r=' + Math.random() + '"></iframe>');
Placing the target origins to the right protocols ensures you won't be sending messages to wrong ones.
Compiled from the comments leading to this answer; I welcome @jeremyisawesome to edit in his final techniques:
Fist choice: Use SSL, across everything. Many users want that, and it is (with the exception of the somewhat higher resource use) a superior option in nearly every way. Also it is the trivial solution.
Sadly, "Because Management" is often a valid reason, and while you can try selling it on the "extra security never hurt anyone" point or whatever, a real solution would be preferred.
I propose the following: duplicate the DOM storage, and use a combination of cookie (with minimal data), AJAX, and a hash function to check if the DOM store needs to be updated. The exact implementation details depend on how much data you have, how frequently it changes, and how frequently users switch sides, but the basic idea is something like this:
Switching between HTTP and HTTPS pages with secure session-cookie -- there are a number of vulnerabilities discussed with switching, but there's some useful stuff there.
It's not technically possible as http as https schemes are deemed different origins as well as no-mix content limitations browsers has (now also in Firfox).
From the specs (Web Storage):
4.3.1 Security
User agents must throw a SecurityError exception whenever any of the members of a Storage object originally returned by the localStorage attribute are accessed by scripts whose effective script origin is not the same as the origin of the Document of the Window object on which the localStorage attribute was accessed.
So what is origin - lets look at CORS (Cross-Origin Resource Sharing) which states:
...origin is composed of [..] the scheme, hostname, and port.
And further:
https to http is not allowed.