質問

の技術的な長所と短所を教えてください。 localStorage , sessionStorage と、セッションと cookies また、どのような場合にどちらかを使うのでしょうか？

どのように解決するのですか？

これは非常に広い範囲の質問であり、多くの長所と短所は状況に応じたものとなります。

どのような場合でも、これらのストレージメカニズムは、個々のコンピュータ/デバイス上の個々のブラウザに固有のものです。セッションをまたいで継続的にデータを保存する必要がある場合は、アプリケーションサーバー側でデータベースを使用する必要がありますが、XMLやテキスト/CSVファイルを使用することもできます。

localStorage、sessionStorage、およびcookieはすべて、クライアントストレージのソリューションです。セッションデータはサーバー上に保持され、あなたの直接の管理下に置かれます。

localStorageとsessionStorage

localStorage と sessionStorage は比較的新しい API で（つまり、すべてのレガシーブラウザがサポートしているわけではありません）、永続性を除いて（API と機能の両方において）ほぼ同じです。 sessionStorage（名前が示すとおり）はブラウザセッションの間のみ有効で（タブまたはウィンドウを閉じると削除）、ただし、ページの再ロードには耐えられます（ソース DOM ストレージガイド - Mozilla Developer Network ).

保存するデータが継続的に利用可能である必要がある場合、localStorageがsessionStorageよりも望ましいことは明らかです。ただし、どちらもユーザーによって消去される可能性があるので、どちらの場合でもデータの継続的な存在に依存しないようにする必要があります。

localStorageとsessionStorageは、ページ間のクライアントスクリプトで必要な非センシティブなデータ（例：プリファレンス、ゲームのスコア）を持続させるのに最適です。localStorageとsessionStorageに保存されたデータは、クライアント/ブラウザ内から簡単に読み取ったり変更したりできるため、アプリケーション内の機密データやセキュリティ関連データの保存に依存してはいけません。

クッキー

このことは、クッキーにも当てはまります。クッキーは、ユーザーによって簡単に改ざんされ、データをプレーンテキストで読み取られる可能性があるため、機密データを保存したい場合は、セッションが唯一の選択肢となります。SSLを使用していない場合、Cookieの情報は、特にオープンWi-Fiでの転送中に傍受される可能性があります。

肯定的な面では、クッキーは、クロスサイトスクリプティング（XSS）/スクリプトインジェクションなどのセキュリティリスクから、HTTPのみのフラグを設定することである程度保護することができます。これは特に認証クッキーで重要です。認証クッキーは、ログオンしているユーザーの詳細を含むトークンを保存するために使用され、もしあなたがそのクッキーのコピーを持っているなら、あらゆる意図と目的であなたは なる ウェブアプリケーションが関係している限り、そのユーザーは、そのユーザーが持っているデータと機能への同じアクセスを持つ。

クッキーは認証やユーザーデータの永続化のために使用されるため。 すべて あるページで有効なクッキーは、ブラウザからサーバーに送信されて すべての これには、最初のページのリクエスト、その後のAjaxリクエスト、すべての画像、スタイルシート、スクリプト、およびフォントが含まれます。このため、クッキーは大量の情報を保存するために使用すべきではありません。また、ブラウザは、クッキーに保存できる情報のサイズに制限を課している場合があります。一般的にクッキーは、認証、セッション、広告の追跡のための識別トークンを保存するために使用されます。トークンは通常、それ自体が人間が読める情報ではなく、アプリケーションやデータベースにリンクされた暗号化された識別子です。

localStorageとsessionStorageとCookieの比較

機能面では、クッキー、セッションストレージ、ローカルストレージは文字列のみを保存できます。設定時にプリミティブ値を暗黙的に変換することは可能ですが（これらは読み込み後に型として使用するために変換し直す必要があります）、オブジェクトや配列はできません（これらをJSONシリアライズしてAPIで保存することは可能です）。セッションストレージは一般的に、サーバーサイドの言語/フレームワークでサポートされているプリミティブやオブジェクトを保存することができます。

クライアントサイドとサーバーサイド

HTTPはステートレスプロトコルであり、WebアプリケーションはWebサイトに戻ったときに以前の訪問からユーザーを識別する方法がないため、セッションデータは通常、繰り返し訪問するユーザーを識別するためにクッキートークンに依存しています（まれにURLパラメータが同じ目的で使用されることがありますが）。データは通常、スライド式の有効期限を持ち（ユーザーが訪問するたびに更新される）、サーバー/フレームワークによっては、データはプロセス内（つまり、Webサーバーがクラッシュまたは再起動するとデータが失われる）または外部で状態サーバーやデータベースに保存されます。これは、Webファーム（特定のWebサイトに複数のサーバーを使用する）を使用する場合にも必要です。

セッションデータはアプリケーション（サーバー側）で完全に制御されるため、機密性や安全性の高いものを置くのに最適な場所です。

サーバーサイドのデータの明らかな欠点はスケーラビリティです。セッションの間、各ユーザーにサーバーリソースが必要となり、クライアントサイドで必要なデータはリクエストごとに送信されなければなりません。ユーザーが別のサイトに移動したり、ブラウザを閉じたりしても、サーバーはそれを知る術がないため、放置されたセッションによってすべてのサーバーリソースが消費されないように、セッションデータは一定時間後に失効する必要があります。したがって、セッションデータを使用する場合は、特に長いフォームを持つページで、データが期限切れになって失われる可能性があることを認識する必要があります。また、ユーザーがクッキーを削除したり、ブラウザーやデバイスを切り替えたりした場合にも、データが失われます。

一部のウェブフレームワーク/開発者は、セッションの失効を避けるために、フォームのあるページから別のページまでデータを持続させるために、HTMLの隠し入力を使用しています。

localStorage、sessionStorage、およびcookieはすべてquot;same-origin"ルールの対象となり、ブラウザは情報を最初に設定したドメイン以外のデータへのアクセスを防ぐ必要があることを意味します。

クライアントストレージ技術に関する詳細については、以下を参照してください。 Html 5に飛び込む .