記事ディレクトリ
序章
Cookie はクライアント側に保存され、セッションはサーバー側に保存されます。どちらもセッションの状態を表すために使用されます。サーバーは、複数の Cookie オブジェクトを作成してクライアントに応答し、それらをクライアントに保存できます。ブラウザー クライアントが要求を送信すると、サーバーが応答できるように、対応する要求パスの下にすべての Cookie 情報が自動的に運ばれます。サーバーはまた、各クライアントに対応する一意のセッション オブジェクトを取得し、オブジェクト内のいくつかの属性を取得して、ユーザーの不正な操作を検証することもできます.ここでは、2 つのステータスの一般的な紹介にすぎません。
クッキー
クッキーの本質と実施原理
- Cookie は、実際にはブラウザーの比較的永続的なストレージ メカニズムであり、HTTP 通信プロトコルのステートレスな性質によって引き起こされる欠陥を最適化し、ユーザー エクスペリエンスを大幅に向上させます。
たとえば、特定のsdnと特定のビデオは、ユーザーが初めてログインするときにユーザーのログイン情報を保存することを選択でき、ユーザーは特定の期間内にWebページに入ると、自動ログインの効果を直接実感できます. ユーザーエクスペリエンスを大幅に最適化。これは、アカウントに対応する Cookie 情報がローカルのハードディスクに保存されているためです. クライアントを操作して対応するサーバーにリクエストを送信すると、保存された Cookie 情報が自動的に送信されます. サーバーはこの情報を受信して検証します.客観的に「ログイン不要」の効果を実感できます。
- Cookie は、ブラウザがハードディスク ファイルにアクセスするための効果的な方法を提供します。
コンピュータの安全のため、ブラウザは js コードがローカル ディスク上のデータにアクセスすることを禁止しています。Cookie メカニズムは、ブラウザがハードディスク ファイルにアクセスするための手段を提供するため、永続的なストレージが存在します。
- 複数の Cookie はサーバーによって作成され、クライアントに応答され、要件に応じてクライアントの実行メモリまたはハード ディスク領域に格納されます. ユーザーがサーバーに要求を送信すると、クライアントは自動的に要求情報を送信します.サーバー側は、応答操作のために Cookie 情報を認識して解析します。
たとえば、クライアントが初めてログインに成功すると、サーバーはユーザー名とユーザー パスワードを含む 2 つの Cookie 情報を作成し、応答をクライアントのメモリまたはハード ディスク領域に格納します。メモリに格納されている場合、クライアントがセッション中に複数回 Web サイトに自動的にログインできるという効果を実現できます。同じセッションで自動ログインの効果を実現できます。大幅に最適化されたユーザー エクスペリエンス。通常の Web サイトで、ユーザーが開くたびにログインするように求められるとしたら、それは何という狂った顧客でしょう! ユーザーのログイン不要を例にとると、Cookie の機能概略図は次のとおりです。
- Cookie の仕組みは Java 独自の仕組みではなく、http プロトコルの一部ですが、Jaba にはそれに対応する Cookie クラスがあり、それぞれの Cookie は name=value で構成され、どちらも型は string です
Web 開発を行っている限り、どのプログラミング言語であっても Cookie の仕組みは不可欠です。クライアントでもサーバーでも、送信される Cookie の形式はキーと値のペアの形式であり、サーバーによって取得される名前または値は文字列の形式です
サーブレットでのクッキーの適用
- サーバー側で Cookie オブジェクトを作成する
Cookie cookie = new Cookie(String name,String value); //Cookie类只提供了这一种形式的构造方法
- サーバー側は、Cookie オブジェクトのライフサイクルと関連するパスを設定します。
cookie.setMaxAge(int second); //设置cookie的生命周期的参数是以秒为单位的。
//例如，设置一个cookie的生命周期为10天，可以设置参数为60*60*24*10
cookie.setPath(String url); /*当服务器端将cookie对象相应保存到客户端时，当客户端发送在这里设置的请求
在这里设置的请求路径时，会自动将与该路径相关的所有cookie信息包含在请求体中发送给服务器
サーバーサイドに設定するCookieオブジェクトのライフサイクルについて
- cookie.setMaxAge(second > 0): cookie オブジェクトは second 秒間存続し、クライアントは受信後にローカル ディスクに cookie オブジェクトを保存します。
- cookie.setMaxAge(second = 0): この Cookie オブジェクトを削除します
- cookie.setMaxAge(second < 0): この Cookie オブジェクトをブラウザーのメモリに保存します。これは 1 つのセッションで有効になり、ブラウザー ウィンドウが閉じられると Cookie は無効になります。
- サーバーは、ライフサイクルとクライアントへのパスを設定した後、cookie オブジェクトに応答し、cookie オブジェクトをクライアントのメモリまたはハードディスク領域に保存します。
response.addCookie(Cookie var);
- サーバー側は、クライアントから送信されたCookie情報を受け取ります
Cookie cookies[] = request.getCookies(); //返回客户端发送的该路径下的所有cookie信息
クライアントから送信されたCookie情報を取得するサーバーについて
サーバーは、リクエストオブジェクトのgetCookies()により、クライアントから送信されたリクエストパスに対応するすべてのCookie情報を取得し、Cookieの配列を返します。クライアントから Cookie 情報を取得できない場合は null を返し、長さ 0 の Cookie 配列は作成せずに返します。
セッション
セッションの本質と実現原理
- セッションオブジェクトはサーバー側に保存されます。これは、本質的にサーバー側がデータを共有するためのメカニズムです。
セッションは、セッション オブジェクトに対応します。複数のセッションは、複数のセッション オブジェクトに対応します。サーバー側でこのセッション オブジェクトに属性を追加できます。このセッションのすべてのリクエストは、このセッション オブジェクトを共有します。
- Web コンテナでは、セッションは実際にはマップ コレクションに似た形式で格納されます. 複数のクライアントが異なるセッション オブジェクトに対応するリクエストを送信します. マップ コレクションのキー値と同様に、セッション オブジェクトのセッション ID が格納されます. このセッション IDこれは、保存用の Cookie の形式でクライアントに応答します; マップ コレクションと同様の値は、キー値に対応する特定のセッション オブジェクトを保存します。Web コンテナでの Seesion の実装原理は次のとおりです。
- ユーザーが初めてリクエストを送信すると、サーバーは新しいセッション オブジェクトを作成し、セッション オブジェクトに属性を追加すると同時に、一意のセッション ID をセッション オブジェクトに関連付けて、クライアントに返します。保存用の Cookie の形式 ; ユーザーが初めてではないリクエストを送信すると、セッション ID を含むリクエスト本文が自動的にサーバーに送信され、サーバーは Cookie 情報のセッション ID に従って、対応するセッション オブジェクトを見つけることができます。返事する。下の図に示すように、
長い間何も操作せずに Web ページを離れ、その Web ページで再度操作を実行すると、その Web ページから再度ログインするように求められる場合があることに気付いたかどうかはわかりません。 webapp の保護メカニズムは、セッション オブジェクトによって実装されます。セッション オブジェクトは有効な期間を持つことができます。セッション オブジェクトは有効期間内にアクセスされない場合、自動的に破棄されます. したがって、ユーザーが再度リクエストした場合、サーバーは、リクエストしたユーザーから送信された sessionid に対応するセッション オブジェクトを見つけることができません.このセッションに不正にアクセスしていること. webapp の場合、それ自体のセキュリティのために、サーバーはユーザーに再度ログインさせて、ユーザーの身元が合法であるかどうかを確認します.
Web アプリケーションの場合、セッションとは、ユーザーがブラウザーを開いて最初のリクエストを送信してからブラウザーを閉じるまでのことを指し、ユーザーがブラウザーを閉じると、セッションは無効になります。ただし、Web サーバーは応答の終了後にクライアントから切断され、ユーザーがブラウザーを閉じたことを認識しないため、ユーザーの現在のセッションに対応するセッション オブジェクトがまだ存在している可能性があります。これが、オンライン バンキング アプリのクライアントが安全な終了ボタンを表示する理由です。このボタンをクリックすることで、ユーザーはサーバーに退出することを伝えることができ、サーバーは Web コンテナー内のこのセッションに対応するセッション オブジェクトを手動で破棄できます。ユーザーとサーバーの安全を確保するため。
サーブレットでのセッションの適用
- サーバー側でセッション オブジェクトを作成/取得する
HttpSession session = request.getSession();
サーバサイドでのセッションオブジェクトの作成・取得について
サーバサイドでは、HttpServletRequest オブジェクトの getSession オブジェクトを介してセッションオブジェクトを作成・取得します。ユーザーがセッションで初めてリクエストを送信するとき、サーバー側にはユーザーに対応するセッションのセッション オブジェクトがなく、 getSession() メソッドがユーザーのセッション オブジェクトを作成します。ユーザーが初めてではないリクエストを送信すると、getSession メソッドはユーザーに対応するセッション オブジェクトを返します。
- サーバー側は、セッション オブジェクトのプロパティを操作します。
session.setAttribute(String name,Object o); //向该会话的session对象中添加属性
Object o = session.getAttribute(String var);//获取该会话中session中的属性
session.removeAttribute(String var); //移除该会话对应session对象中的var属性及其value
- サーバー側はセッション オブジェクトを破棄します
session.invalidate();
HttpServletRequest，Session，ServletContext
3 つすべてをデータ ドメイン共有のツールとして使用できますが、違いは何ですか?
- 1 つ目は、要求レベルでデータを共有するための HttpServletRequest (要求ドメインとも呼ばれる) です。
リクエスト オブジェクトのライフ サイクルは非常に短く、リクエストが終了するとリクエスト オブジェクトは破棄され、リクエスト フィールドのデータは存在しなくなります.このデータ フィールド共有方法は、異なるリクエスト転送間でよく使用されます。
- 2 つ目は、ユーザー レベルのセッション ドメインとも呼ばれるセッションです。
ユーザーのセッションはセッション オブジェクトに対応し、このセッション オブジェクトに追加されたデータは、このセッションでどのような要求が行われても共有できます。異なるユーザー セッションは異なるセッションに対応し、各セッション オブジェクトは個々の顧客に関連付けられます。
- 最後に、アプリケーション ドメインとも呼ばれる ServletContext はプロジェクト レベルです。
ServletContext オブジェクトに追加された共有データ フィールドはプロジェクト全体であり、すべてのクライアントで共有される
3 つのフィールド間のサイズ関係
- HttpServletRequest < セッション < ServletContext
3つの使い方の原則
- できるだけ小さなドメインを使用する