Ответ 1

Составлено из комментариев, ведущих к этому ответу; Я приветствую @jeremyisawesome для редактирования в своих последних методах:

Выбор кулака: используйте SSL, через все. Многие пользователи этого хотят, и это (за исключением несколько более высокого использования ресурсов) превосходный вариант почти во всех отношениях. Также это тривиальное решение.

К сожалению, "потому что управление" часто является веской причиной, и, хотя вы можете попробовать продать его на "лишней безопасности никогда не причинять вреда кому-либо" или что-то еще, было бы предпочтительным реальное решение.

Я предлагаю следующее: дублировать хранилище DOM и использовать комбинацию cookie (с минимальными данными), AJAX и хэш-функцию, чтобы проверить, нужно ли обновлять хранилище DOM. Точные детали реализации зависят от того, сколько данных у вас есть, как часто это изменяется, и как часто пользователи переключаются с сторон, но основная идея заключается в следующем:

• сохранить данные в DOM вместе с хешем.
• отправить хеш в cookie вместо полных данных.
• JS проверяет соответствие хэш файла cookie и DOM-данных.
• Если DOM определен как устаревший, используйте AJAX для получения новых данных для DOM и обновите его асинхронно.

Переключение между страницами HTTP и HTTPS с помощью безопасного сеансового файла cookie - существует ряд уязвимостей, обсуждаемых при переключении, но там есть некоторые полезные материалы.

Ответ 2

localStorage/sessionStorage ssl/non-ssl совместное использование в производстве

То, как я это делал, это использовать iframe, который выполняет postMessage для своего родителя. IFrame всегда находится на https, но родитель может быть либо http, либо https. Это решение предполагает, что модификации относятся к SSL только для хранения и синхронизируют его для не SSL, но вы можете адаптировать его для отправки изменений в обоих направлениях, поэтому родитель non ssl отправляет изменения в дочерний файл ssl.

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:

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>');

Размещение целевого источника в правильных протоколах гарантирует, что вы не будете отправлять сообщения неправильным.

Ответ 3

Это не технически возможно, поскольку http-схемы https считаются разными источниками, а также ограничения содержания контента без смешивания (теперь также в Firfox).

Из спецификаций (Web Storage):

4.3.1 Безопасность

Пользовательские агенты должны вызывать исключение SecurityError всякий раз, когда любой из члены объекта хранения, первоначально возвращенного localStorage доступ к атрибутам осуществляется с помощью сценариев, эффективный источник script не является то же, что и происхождение документа объекта Window, на котором к нему был добавлен атрибут localStorage.

Итак, что такое происхождение - посмотрим на CORS (совместное использование ресурсов Cross-Origin) в котором говорится:

... origin состоит из [..] схемы , имени хоста и порта.

И далее:

https to http не разрешено.