Token、Session、Cookieを徹底的に把握しましょう。

クッキー、セッションとトークンは、Web開発に従事するプログラマにとって新しいものではありません、彼らはすべてのセッション状態のソリューションです。Httpプロトコルのステートレス性質は、プログラムが同じユーザーが開始したかどうか、複数のリクエストを区別することはできませんにつながるので、トークン、セッションとクッキーの技術は、ステートレスの問題を解決するために。

トークン

名前が示すようにトークンは、トークン、資格情報、キー、このキーだけで、ドアを開けることができます。トークンは、一般的に、Webシステムなどのサーバーによって生成され、ユーザーがログインすると、サーバーは、ユーザー名とパスワードをチェックし、サーバーを介してトークンが生成され、同時に、refreshTokenと有効期限を生成し、その後、クライアントに戻ってrefreshTokenとトークン。サーバは、現在のトークンが存在するか、有効期限が切れているかを判断します。トークンが存在しないか有効期限が切れている場合、リクエストは拒否されます。トークンの有効期限が切れた場合は?もちろん、他のオプションがあるかもしれません。例えば、トークンだけを生成して、リクエストのたびに有効期限をリフレッシュする、などです。もし長い間リフレッシュ時間がなければ、トークンは失効します。

セッション

セッションとはセッションのことで、サーバー側の操作です。あなたが初めてWebサイトを訪問したとき、サーバーはセッションを生成し、彼に対応するsessionidがあります。このセッションはメモリに保存され、あなたは、現在のログインユーザの情報などのセッションに情報を書き込むことができます。sessionidはクライアントに返され、クライアントは、一般的に保存するクッキーを使用します。もちろん、このクッキーは人間が書き込む必要はありません。tomcat コンテナを例にしてみましょう。バックエンドがHttpServletRequestオブジェクトのgetSessionメソッドを呼び出すと、tomcatは内部のjsessonidを生成します。レスポンスヘッダ情報

HTTP/1.1 200 OK

Set-Cookie: JSESSIONID=xxxxxxxxxxxxxxxxxxx

このjessionidがクッキーに書き込まれます。その後、jessionidはクッキーを介してサーバーに渡されます。

ここでは、セッションデータがメモリに格納され、問題が発生し、サービスが分散配置されている場合、多くのマシンがあり、ログインする最初の時間かもしれない、ユーザーの情報は、セッションに格納されていますが、後でBのマシンに要求し、Bのマシンは、ユーザーのセッションを取得することはできません。また、セッションは、メモリに格納され、その後、サーバーが再起動すると、セッションが失われます、これはそれの欠点です。現在、セッション共有、iphash、セッションの永続化などの技術も、上記の問題を解決することができます。

クッキーはブラウザのポリシーです。前述のsessionidはクッキーに保存されます。httpプロトコルがステートレスであることを知って、クッキーはこの問題を解決するために使用されます。クッキーは、前述のトークン、セッションIDのような、サーバーから返されるユーザー情報の一部を保存するために使用することができます。httpがステートフルでないように、リクエストのソース。

クッキーの注意点は以下の通りです：

• 1、クッキーはクライアントに保存されるため、安全ではなく、人間によってクリアされる可能性があります。
• 2.クッキーには有効期限が設定されています。有効期限を設定しない場合、クッキーは現在のブラウザのセッション時間であり、ブラウザを閉じた場合、クッキーは存在しません。有効期限がある場合、クッキーはハードドライブに保存され、ブラウザが閉じてもクッキーに影響を与えず、次にブラウザを開いたときに、クッキーはまだ存在します！
• 3.クッキーのサイズ制限は4KBです。

サーバはトークンを生成し、ユーザ情報とトークンを関連付け、トークンはブラウザに返され、クッキーに保存されます。後続のリクエストはクッキーからクークやトークンをパラメータパスに運びます。

この記事は トランスコードされました。