セッションの動作原理に関する Java サーブレット グラフィック コードの詳細な説明

この記事では、主にサーブレット セッションの動作原理を紹介します。編集者がそれを参考にさせていただきます。エディターをフォローして見てみましょう

Session の基本的な動作原理を理解するために。まず、セッション中に同じブラウザが複数の Web リソースにアクセスする状況を見てみましょう。

1. ブラウザが特定のサーブレットを取得したい場合。リクエスト オブジェクトからセッション オブジェクトを取得すると (最初の取得も作成されます)、サーバーはこのセッション オブジェクトの ID を作成します: JSESSIONID

2 同時に、このセッションはブラウザーへの応答中に、 id JSESSIONID Cookie の形式でクライアント ブラウザに送信されます。この時点では Cookie サーバーには有効な時間が設定されていないため、ハードディスク ファイルではなくブラウザのキャッシュに保存されます。

3. ユーザーがこのセッション中に他のサーブレットにアクセスし続けると、サーブレットはリクエスト オブジェクトからセッション オブジェクトを取得します。このときのセッション オブジェクトの取得は、この Cookie がある場合、このセッションを再度作成する必要はありませんが、サーバーに同じ JSESSIONID 値を持つセッションを直接クエリすることができます。得られる。

要約すると、セッションは Cookie に基づいています。

(注: Cookie は全能ではありません。Session は最初に Cookie に依存しますが、Cookie が使用できない場合もあります。このとき、Session はリクエストによって送信された URL アドレスに JSESSIONID があるかどうかを確認します。)

Session の隠し Cookie、検証するための小さな実験を行うことができます。Web プロジェクト [myservlet] の下に、それぞれ SessionDemo1 と SessionDemo2 という名前の 2 つのサーブレットを作成します。

   HttpSession session = request.getSession();
   String data = "Message from SessionDemo";
   session.setAttribute("data", data);

ブラウザで HttpWatch を開いて SessionDemo1 にアクセスします。初めてサーブレットにアクセスするので、ブラウザへの SessionDemo1 の応答を確認します。

確かに、サーバーはブラウザにはこの JSESSIONID という名前の Cookie があり、開いているブラウザで SessionDemo2 に再度アクセスすると、HttpWatch でリクエスト パッケージの内容を観察して次の情報を見つけます。

サーバーに再度アクセスすると、ブラウザはこの名前の JSESSIONID を取得します。 Cookie がサーバーに与えられ、サーバーは Cookie 内の JSESSIONID 値を使用して、サーバー内のブラウザー用に以前に作成されたセッションを見つけます。

ブラウザを閉じると、この Cookie には「setMaxAge」が設定されていないため、この Cookie はブラウザのバッファ内にのみ存在し、ブラウザを閉じると破棄されます。ブラウザを閉じた後もセッションを存続させたい場合は、セッション Cookie を手動で上書きし、上書き Cookie の有効期間と有効なパスを設定する必要があります。

この Cookie の値 (JSESSIONID の値) は、Session
の getId() メソッドを通じて取得できます。

1、カバレッジ有効時間:

サーバーがブラウザーのセッションを作成した後、ユーザーがセッションを操作しなかった場合 (またはブラウザーが閉じられた後)、セッションはデフォルトで 30 分間維持されることに注意してください。 )。これは Tomcat の [web.

もちろん、すべてのサーバーでセッションの破棄時間をグローバルに設定したくない場合は、web.xml ファイルに と を追加して設定をカスタマイズできます。各Webアプリケーション。
注: Session オブジェクトの validate() メソッドを使用して、セッションをすぐに破棄することもできます。

これに関して、セッション Cookie を上書きしてハードディスク ファイルに保存する場合、設定する Cookie の有効期間はサーバーのデフォルトのセッション タイムアウト時間を超えてはなりません。

2、有効なパスをカバーします:

Cookie オブジェクトを作成し、「setPath」を設定しない場合、Cookie の有効なパスは、Cookie を作成したプログラム (通常はサーブレット) になります。このプロセス中、ブラウザーは Cookie を保持するだけであり、実際には「接続されていない」状態になります。この Web アプリケーションの他のリソースにアクセスするためにセッションを使用することはできなくなります。

サーブレットが初めてアクセスされたときに、ブラウザー用にサーバーによって作成されたセッション内の Cookie の有効なパスを見てみましょう:

可以看到这个服务器默认将JSESSIONID这个cookie的有效路径设置为创建这个Session的web工程根目录。所以我们要覆盖Session中的cookie时也应该设置路径为该web工程根目录。

好，接下来对上面那个Servlet的例子进行改造，我们只需要在SessionDemo1中修改就行，因为这个首次将Session的cookie返回给客户端，修改后代码如下：

   HttpSession session = request.getSession();
   String data = "Message from SessionDemo";
   session.setAttribute("data", data);
     
   Cookie cookie = new Cookie("JSESSIONID", session.getId());
   cookie.setMaxAge(30*60);
   cookie.setPath("/myservlet");
   response.addCookie(cookie);

这样，当我们打开浏览器访问了SessionDemo1之后，就能在存放cookie的目录中找到该cookie，如果我们通过HttpWatch来查看可以看到重名的这个cookie：

虽然JSEESIONID这个cookie重名了，没有关系，因为其值都是一样的，并且如果我们将浏览器关闭后，没有设置cookie有效时间的（也是原先Session发来的）cookie将不复存在(存在浏览器缓存中，浏览器关闭就被销毁)，这时重新打开一个浏览器，再去访问SessionDemo2依然能获取到原来Session中保存的内容：

注意，这是另外打开浏览器窗口访问的SessionDemo2！！另附：

通过这里我们可以看到，我们人为地将原先Session定义的cookie给替换了，而Session并不知道，只要能获得“JSESSIONID”这个cookie，它就认为cookie是存在的，可以从这个cookie中id值获取以前保存的信息，因此我们实现了一台主机共享一个Session，此时，当浏览器关闭，或者说结束一个会话后，依然能获取Session来获取之前保存的数据。

以上がセッションの動作原理に関する Java サーブレット グラフィック コードの詳細な説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。