Share dom storage between http and https

Question

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 be accessed by the current protocol.

I'd like to be able to store a piece of information via javascript on the non-ssl(http) portion of my site and access it on the SSL (https) portion of my site.

Does anyone know of a good way to share stored client-side information between ssl and non-ssl pages?

I know I can always default to a cookie.. but I hate the idea of having to send the cookie back and forth for every single request.

Answer 1

localStorage / sessionStorage ssl / non-ssl sharing in production

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.

Answer 2

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:

1. save data to DOM, along with its hash.
2. send hash in cookie instead of full data.
3. JS checks that cookie hash and DOM data match.
4. If DOM is determined to be out of date, use AJAX to acquire new data for DOM, and update it asynchronously.

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.