http/httpsでhtml5 sessionStorageをクリアします

Question

私はhttp://www.example.comとhttps://www.example.comという2つのウェブサイトを持っています。私はHTML5セッションストレージを使用してユーザーの設定を保存しています。 ユーザーがhttp://www.example.comに到着し、ajax経由でいくつかのデフォルト設定を読み込みます。 ログインが必要なページを参照し、https://www.example.com/login.htmlに送信されます。 ログインが完了したら、http://www.example.comに送信されます。ログインしているため、サーバーから新しい設定を取得する必要があります。問題は、httpとhttpsが異なる起源であり、セッションストレージを共有できないことです。動作しない、私が試した

物事： はちょうど私のデータを消去するにはsessionStorage.removeItem（「キー」）を実行しますが、これはそれ自身のブラウジングを持っているようだiframe内のページhttp://www.example.com/clearSession.htmlのロードコンテキストでは動作しません。

私はその仕事を試してみましたが、私は使いたくありません： クッキーを使用する。 httpとhttpsはクッキーを共有することができますが、これは私のすべてのユーザー設定がすべてのリソース要求とともにサーバーに送信されることを意味します。これは通常約4kですが、最大1MBのデータになる可能性があります。いいえ、私は自分のリソースを別のドメインにホストすることはできません。

設定をキャッシュしないで、設定を取得するたびにリクエストを行います。古いブラウザではセッションストレージをサポートしていないので、これをやっていますが、ページの読み込みが遅くなり、データベースに余分な負荷がかかります。

Answer 1

この問題をどのように解決したかは分かりますが、ローカルのsessionStorageは関係ありません。私たちは、サーバー側のセッションを使用して、ユーザーのログインデータ（ユーザー名、IDなど）を認証サーバーに送信してから保存します。認証される前に、AJAXを使用してプリファレンスデータを収集して、サーバーのセッションスコープに格納できるサーバー上のWebサービスにこれらのプリファレンスを戻すことができます。しかし、RESTfulモデルは、サーバーサイドセッションの使用を前提としているため、これを破ることになります。それはあなたのサーバー言語とWebサービスの設定方法に依存します。

私はあなたがいつもその起源の問題にぶつかると思います。なぜなら、それは一般的にローカルストレージに設計された制限だからです。

Answer 2

すべてを現在の標準であるhttpsに切り替えます。