ホームページ > 記事 > ウェブフロントエンド > Cookie/セッションメカニズムの概要
Cookie/セッションメカニズムの概要
- 一个新手オリジナル
- 2017-09-23 09:09:551604ブラウズ
セッション追跡は、Web プログラムで一般的に使用されるテクノロジーであり、ユーザーのセッション全体を追跡するために使用されます。一般的に使用されるセッション追跡テクノロジは、Cookie とセッションです。 Cookieはクライアント側で情報を記録することでユーザーの身元を特定し、Sessionはサーバー側で情報を記録することでユーザーの身元を特定します。
この章では、Cookieとセッションの仕組みを体系的に説明し、Cookieが使用できない場合とセッションが使用できない場合を比較して説明します。
1.1 Cookieのメカニズム
プログラムでは、セッションの追跡は非常に重要です。理論的には、あるユーザーのすべてのリクエスト操作は同じセッションに属する必要があり、別のユーザーのすべてのリクエスト操作は別のセッションに属する必要があり、この 2 つを混同することはできません。たとえば、ユーザー A がスーパーマーケットで購入した商品は、ユーザー A がいつ購入したとしても、同じセッションに属しており、ユーザー B やユーザー C のショッピング カートに入れることはできません。同じセッションに属していません。
Web アプリケーションは HTTP プロトコルを使用してデータを送信します。 HTTP プロトコルはステートレス プロトコルです。データ交換が完了すると、クライアントとサーバー間の接続が切断され、再度データを交換するには新しい接続を確立する必要があります。これは、サーバーが接続からセッションを追跡できないことを意味します。 つまり、ユーザー A がアイテムを購入してショッピング カートに入れます。そのアイテムが再度購入されると、サーバーはその購入がユーザー A のセッションに属するかユーザー B のセッションに属するかを判断できません。このセッションを追跡するには、メカニズムを導入する必要があります。
Cookieはそのような仕組みです。これにより、HTTP プロトコルのステートレスな欠点を補うことができます。 Session が登場する前は、基本的にすべての Web サイトはセッションを追跡するために Cookie を使用していました。
1.1.1 Cookie とは
Cookie とは「甘いクッキー」を意味し、W3C 組織によって提案され、Netscape コミュニティによって最初に開発されたメカニズムです。現在、Cookie は標準となっており、IE、Netscape、Firefox、Opera などの主流ブラウザはすべて Cookie をサポートしています。
HTTP はステートレス プロトコルであるため、サーバーはネットワーク接続だけからクライアントの ID を知る方法がありません。どうやってするの？ クライアントにパスを発行してください。誰が訪問しても、自分のパスを持参する必要があります。このようにして、サーバーはパスからクライアントの ID を確認できます。これがクッキーの仕組みです。
Cookie は実際には短いテキスト情報です。クライアントはサーバーに要求し、サーバーがユーザーのステータスを記録する必要がある場合、応答を使用してクライアントのブラウザーに Cookie を発行します。クライアントのブラウザは Cookie を保存します。ブラウザが Web サイトを再度リクエストすると、ブラウザはリクエストされた URL を Cookie とともにサーバーに送信します。サーバーはこの Cookie をチェックしてユーザーのステータスを識別します。サーバーは必要に応じて Cookie の内容を変更することもできます。
ウェブサイトが発行したCookieを確認するのは簡単です。ブラウザのアドレスバーに javascript:alert (document.cookie) と入力するだけです (表示するにはインターネット接続が必要です)。図 1.1 に示すように、JavaScript スクリプトはダイアログ ボックスをポップアップ表示し、この Web サイトによって発行されたすべての Cookie の内容を表示します。
図 1.1 Baidu Web サイトが発行する Cookie
図 1.1 のポップアップダイアログボックスに表示されているのは、Baidu Web サイトの Cookie です。 BAIDUID の最初の行には、作成者の ID helloweenvsfei が記録されていますが、Baidu は特別な方法を使用して Cookie 情報を暗号化します。
注: Cookie 機能にはブラウザのサポートが必要です。
ブラウザがCookieをサポートしていない場合（ほとんどの携帯電話のブラウザなど）、またはCookieを無効にしている場合、Cookie機能は無効になります。
ブラウザが異なると、Cookie を保存する方法も異なります。
IE ブラウザは、「C:Documents and Settings Your Username Cookies」フォルダーにテキスト ファイルとして保存します。各テキスト ファイルには 1 つの Cookie が保存されます。
1.1.2 ユーザーの訪問数を記録する
Javaでは、Cookieはjavax.servlet.http.Cookieクラスにカプセル化されます。各 Cookie は、この Cookie クラスのオブジェクトです。サーバーは、Cookie クラスのオブジェクトを操作することによって、クライアントの Cookie を操作します。 request.getCookie() を介してクライアントによって送信されたすべての Cookie を取得し (Cookie[] 配列の形式で返されます)、response.addCookie(Cookiecookie) を介してクライアントに Cookie を設定します。
Cookie オブジェクトは、キーと値の属性ペアを使用してユーザーのステータスを保存し、1 つの Cookie オブジェクトは 1 つの属性ペアを保存し、1 つのリクエストまたは応答で複数の Cookie を同時に使用します。 Cookie クラスはパッケージ javax.servlet.http.* の下にあるため、このクラスを JSP にインポートする必要はありません。
1.1.3 Cookie はドメイン名を越えることはできません
多くの Web サイトで Cookie が使用されています。たとえば、Google はクライアントに Cookie を発行しますし、Baidu もクライアントに Cookie を発行します。 Google にアクセスするときに、ブラウザには Baidu が発行した Cookie も含まれますか?それとも、Google は Baidu が発行した Cookie を変更できるのでしょうか? 答えはノーです。Cookie はドメイン名を越えることはできません。 Cookie の仕様によれば、ブラウザは Google にアクセスするときに Google の Cookie のみを送信しますが、Baidu の Cookie は送信しません。 Google は Google の Cookie のみを操作できますが、Baidu の Cookie は操作できません。
Cookieはクライアント側のブラウザによって管理されます。ブラウザは、Google が Baidu の Cookie ではなく Google の Cookie のみを操作することを保証できるため、ユーザーのプライバシーとセキュリティが確保されます。ブラウザは、ドメイン名に基づいて、Web サイトが別の Web サイトの Cookie を操作できるかどうかを判断します。 Google と Baidu のドメイン名は異なるため、Google は Baidu の Cookie を操作できません。
ウェブサイトimages.google.comとウェブサイトwww.google.comはGoogleに属しますが、ドメイン名が異なり、相互のCookieを操作できないことに注意してください。
注: ユーザーは、Web サイト www.google.com にログインした後、images.google.com にアクセスするとログイン情報がまだ有効であることがわかりますが、これは通常の Cookie では不可能です。これはGoogleが特殊な処理を行っているためです。 Cookie はこの章の後半で同様に扱われます。
1.1.4 Unicodeエンコーディング: 中国語を保存
中国語と英語の文字は異なります。中国語はUnicode文字でメモリ内に4文字を占有しますが、英語はASCII文字でメモリ内に2文字しか占有しませんお祭り。 Cookie で Unicode 文字を使用する場合、Unicode 文字をエンコードする必要があります。エンコードしないと文字化けしてしまいます。
ヒント: Cookie に保存された中国語の文字はエンコードのみ可能です。通常、UTF-8 エンコーディングを使用できます。 GBK などの中国語エンコードはブラウザーでサポートされていない可能性があり、JavaScript は GBK エンコードをサポートしていないため、使用することはお勧めできません。
1.1.5 BASE64エンコーディング: バイナリ画像を保存
CookieはASCII文字やUnicode文字だけでなく、バイナリデータも使用できます。たとえば、デジタル証明書はセキュリティを提供するために Cookie で使用されます。バイナリ データを扱う場合もエンコードが必要です。
% 注: このプログラムは、バイナリ コンテンツを Cookie に保存できることを示すためにのみ使用されており、実用的ではありません。ブラウザはサーバーをリクエストするたびに Cookie を送信するため、Cookie の内容が多すぎてはなりません。そうしないと速度に影響します。 Cookie の内容は小さくても正確である必要があります。
1.1.6 Cookie のすべてのプロパティを設定する
名前と値に加えて、Cookie には他にもよく使用されるプロパティがいくつかあります。各プロパティはゲッター メソッドとセッター メソッドに対応します。 Cookie クラスのすべてのプロパティを表 1.1 に示します。
表 1.1 Cookie の共通属性
属性名 |
説明説明 |
文字列名 |
Cookie の名前。クッキーが作成されると、名前は変更できません |
オブジェクトの値 |
このクッキーの値。値が Unicode 文字の場合、その文字をエンコードする必要があります。値がバイナリ データの場合は、BASE64 エンコードを使用する必要があります |
int maxAge |
Cookie の有効期限が切れる時間 (秒単位)。正の場合、Cookie は maxAge 秒後に期限切れになります。負の数の場合、Cookie は一時的な Cookie であり、ブラウザを閉じると無効になり、ブラウザはいかなる形式でも Cookie を保存しません。 0の場合はCookieを削除することを意味します。デフォルトは -1 です |
boolean secure |
この Cookie が安全なプロトコルを使用してのみ送信されるかどうか。セキュリティプロトコル。セキュリティ プロトコルには、ネットワーク上で送信する前にデータを暗号化する HTTPS、SSL などが含まれます。デフォルトは false です |
文字列パス |
この Cookie によって使用されるパス。 「/sessionWeb/」に設定すると、contextPath が「/sessionWeb」であるプログラムのみが Cookie にアクセスできます。 「/」に設定すると、このドメイン名の contextPath によって Cookie にアクセスできます。最後の文字は「/」である必要があることに注意してください。 |
文字列ドメイン |
Cookieにアクセスできるドメイン名。 「.google.com」に設定すると、「google.com」で終わるすべてのドメイン名がこの Cookie にアクセスできます。最初の文字は「.」である必要があることに注意してください。 |
文字列コメント |
このCookieの使用の説明。ブラウザは Cookie 情報を表示するときにこの説明を表示します |
int version |
Cookie で使用されるバージョン番号。 0 は Netscape の Cookie 仕様に従うことを意味し、1 は W3C の RFC 2109 仕様に従うことを意味します |
1.1.7 Cookieの有効期間
CookieのmaxAgeはCookieの有効期間を決定します。単位は秒です。 Cookie では、maxAge 属性は getMaxAge() メソッドと setMaxAge(int maxAge) メソッドを通じて読み書きされます。
maxAge 属性が正の数値の場合、Cookie は maxAge 秒後に自動的に期限切れになることを意味します。ブラウザは Cookie を正の maxAge で保持します。つまり、Cookie を対応する Cookie ファイルに書き込みます。お客様がブラウザを閉じるかコンピュータを閉じるかに関係なく、maxAge 秒前であれば、Web サイトにログインするときも Cookie は有効です。以下のコード内の Cookie 情報は永久に有効です。
Cookie cookie = new Cookie("username","helloweenvsfei"); // 新しい Cookie を作成します
cookie.setMaxAge(Integer.MAX_VALUE) // ライフサイクルを MAX_VALUE に設定します
response .addCookie(cookie); // クライアントへの出力
注: クライアントから Cookie を読み取るとき、maxAge を含む他のプロパティは読み取ることができないため、送信されません。ブラウザが Cookie を送信する場合、名前と値の属性のみが送信されます。 maxAge 属性は、Cookie の有効期限が切れているかどうかを判断するためにブラウザによってのみ使用されます。
1.1.8 Cookieの変更と削除
Cookieは変更または削除の操作を提供しません。 Cookie を変更する場合は、同じ名前で新しい Cookie を作成し、それを応答に追加して元の Cookie を上書きするだけです。
Cookie を削除したい場合は、同じ名前で新しい Cookie を作成し、maxAge を 0 に設定し、それをレスポンスに追加して元の Cookie を上書きするだけです。これは 0 であり、負の数ではないことに注意してください。負の数は他の意味を表します。読者は、上記の例のプログラムを通じてさまざまな属性を確認および設定できます。
注: Cookie を変更または削除する場合、名前、パス、ドメインなど、新しく作成された Cookie のすべての属性 (値と maxAge を除く) が元の Cookie とまったく同じである必要があります。そうしないと、ブラウザはそれを 2 つの異なる Cookie として扱い、上書きしないため、変更と削除が失敗します。
1.1.9 Cookie ドメイン名
Cookie はドメイン名を越えることはできません。ドメイン名 www.google.com によって発行された Cookie は、ドメイン名 www.baidu.com には送信されません。これは、Cookie のプライバシー セキュリティ メカニズムによって決定されます。プライバシー セキュリティ メカニズムにより、Web サイトが他の Web サイトから Cookie を違法に取得するのを防ぐことができます。
通常の状況では、同じ第 1 レベル ドメイン名の下にある 2 つの第 2 レベル ドメイン名 (www.helloweenvsfei.com と Images.helloweenvsfei.com など) は、Cookie を対話的に使用できません。これは、2 つのドメイン名が厳密に一致していないためです。同じ。 helloweenvsfei.com 名の下にあるすべての第 2 レベルのドメイン名がこの Cookie を使用できるようにするには、Cookie のドメイン パラメーターを設定する必要があります。例:
Cookie cookie = new Cookie("time"," 20080808"); // 新しい cookie を作成します
cookie.setDomain(".helloweenvsfei.com"); //有効期間
response.addcookie (cookie) // クライアントへの出力
読者は、ローカル マシンの C:WINDOWSsystem32driversetc にある hosts ファイルを変更して複数の一時ドメイン名を構成し、setCookie.jsp プログラムを使用してクロスドメイン Cookie 検証ドメイン属性を設定できます。
注: ドメインパラメータはドット (「.」) で始める必要があります。さらに、名前は同じでドメインが異なる 2 つの Cookie は、2 つの異なる Cookie です。まったく異なるドメイン名を持つ 2 つの Web サイトで Cookie を共有したい場合は、ドメイン属性にそれぞれ 2 つのドメイン名を指定して 2 つの Cookie を生成し、クライアントに出力します。
1.1.10 Cookie のパス
domain 属性は Cookie にアクセスするために実行されるドメイン名を決定し、path 属性は Cookie へのアクセスを許可するパス (ContextPath) を決定します。たとえば、/sessionWeb/ にあるプログラムのみに Cookie の使用を許可する場合は、次のように記述できます。
Cookie cookie = new Cookie("time","20080808") // 新しい Cookie を作成します
cookie.setPath(" /セッション/" ) ; path 属性は記号「/」で終わる必要があります。同じ名前で同じドメインを持つ 2 つの Cookie も、2 つの異なる Cookie です。
注: ページは、それが属するパスの Cookie のみを取得できます。たとえば、/session/test/a.jsp はパス /session/abc/ の Cookie を取得できません。ご使用の際はご注意ください。1.1.11 Cookieのセキュリティプロパティ
HTTPプロトコルはステートレスであるだけでなく、安全でもありません。 HTTP プロトコルを使用したデータは暗号化なしでネットワーク上に直接送信されるため、傍受される可能性があります。 HTTP プロトコルを使用して機密性の高いコンテンツを送信することには、隠れた危険があります。 HTTP などの安全でないプロトコルで Cookie を送信したくない場合は、Cookie の secure 属性を true に設定できます。ブラウザは、そのような Cookie を HTTPS や SSL などの安全なプロトコル経由でのみ送信します。次のコードは、secure 属性を true に設定します。
Cookie cookie = new Cookie("time", "20080808") // 新しい Cookie を作成します;
response.addCookie(cookie);
ヒント: secure 属性は Cookie の内容を暗号化できないため、絶対的なセキュリティを保証することはできません。高いセキュリティが必要な場合は、漏洩を防ぐためにプログラム内でCookieの内容を暗号化および復号化する必要があります。
1.1.12 JavaScriptはCookieを操作します
Cookieはブラウザ側に保存されるため、ブラウザはCookieを操作するための前提条件を備えています。ブラウザは JavaScript や VBScript などのスクリプト プログラムを使用して Cookie を操作できます。ここでは、JavaScript を例として、一般的に使用される Cookie の操作を紹介します。たとえば、次のコードはこのページのすべての Cookie を出力します。
<script>document.write(document.cookie);</script>
JavaScript は Cookie を自由に読み書きできるため、一部の善良な人々は JavaScript プログラムを使用して他の Web サイト上のユーザーの Cookie を盗み見したいと考えています。しかし、これは無駄です。W3C 組織は、JavaScript による Cookie の読み書きによって引き起こされるセキュリティ リスクを以前から認識しており、W3C の標準ブラウザでは、JavaScript が独自のもの以外の Cookie を読み書きできないように予防策を講じてきました。 Webサイト。つまり、Web サイト A の JavaScript プログラムが Web サイト B の Cookie を読み書きしても、結果は得られません。
1.1.13 ケース: 永久ログイン
ユーザーが自宅のコンピューターでインターネットサーフィンをしている場合、ログイン時にそのログイン情報を記憶できます。次回ログインするときに再度ログインする必要はありません。訪問するだけで直接アクセスできます。実装方法は、アカウント番号やパスワードなどのログイン情報をCookieに保存し、Cookieの有効期限を管理し、次回訪問時にCookie内のログイン情報を確認する方法です。
ログイン情報を保存するには多くのオプションがあります。最も直接的なのは、ユーザー名とパスワードを Cookie に保存し、次回アクセスしたときに Cookie 内のユーザー名とパスワードを確認し、データベースと比較することです。これは危険な選択です。通常、パスワードなどの重要な情報は Cookie に保存されません。別の解決策
は、パスワードを暗号化して Cookie に保存し、次回のアクセス時に復号化してデータベースと比較することです。 この解決策は若干安全です。パスワードを保存したくない場合は、ログイン タイムスタンプを Cookie とデータベースに保存し、ユーザー名とログイン タイムスタンプのみを検証することもできます。 これらのスキームはすべて、アカウントを確認するときにデータベースにクエリを実行する必要があります。
この例では、ログイン時に 1 回だけデータベースにクエリを実行し、今後ログイン情報を確認するためにアクセスするときにデータベースにクエリを実行しない別のソリューションを使用します。これを実現する方法は、
特定のルールに従ってアカウントを暗号化し、アカウントと一緒に Cookie に保存することです。次回アクセスするときは、アカウントの暗号化ルールが正しいかどうかを判断するだけです。 この例では、アカウントは account という名前の Cookie に保存され、アカウントとキーは MD1 アルゴリズムを使用して暗号化されてから、ssid という名前の Cookie に保存されます。検証中に、Cookie 内の暗号化されたアカウント番号とキーが Cookie 内の SSID と等しいかどうかを検証します。関連するコードは次のとおりです: コード 1.8 loginCookie.jsp
<%@ page language="java"pageEncoding="UTF-8" isErrorPage="false" %>
<%! :cookie@helloweenvsfei. " " " : ss; null の場合は空を返します
" " char hexDigits [] = { '0','1', '2', '3', '4', '1', '6', '7', '8' , '9',
'a', ' b', 'c', 'd', 'e', 'f' }; バイト
MessageDigestmdTemp = MessageDigest .getInstance("MD1"); // 取得md1
mdtemp.update（strtemp）;
for (int i = 0; i< i++) { // ループ出力
byte byte0 =md[i];
str[k++] =hexDigits[byte0 >>& gt;
str[k++] catch (Exception e){return null; }
}
% >
<%
request.setCharacterEncoding("UTF-8") // リクエストのエンコーディングを設定します
response.setCharacterEncoding("UTF-8");
String action = Request.getParameter ("Action"); // アクションパラメータを取得します。{// login
int timeout = newInteger(request.getParameter("timeout"));
String ssid =calcMD1(account + KEY) // アカウントとキーをMD1で暗号化して保存
CookieaccountCookie = new Cookie( 「アカウント」、
/ /新しいCookie.setMaxage（Timeout）; ‐ ‐ ‐ use using ssidCookie's ssidCookie- の本 // このページを改訂し、ブラウザのキャッシュページコンテンツを禁止するタイムスタンプを付けました
Response.SendRedirect (request.getRequesturi () + 「？＋システム」
ookie = 新しい Cookie ("ssid", ""); Cookie、内容は空です
SSIDCOOKIE.SETMAXAGE (0) // 有効期間を 0 に設定し、
Response.addcookie (AcountCookie) // クライアントに出力します。アカウント
String ssid = null; Re if (request.getCookies ()! = NULL) {//K if (cookie.getName (). Equals ("Account") // Cookie の名前が付いている場合 account
login = ssid.equals（calcmd1（account + key））; = ログイン ? "ようこそ" : "まずログインしてください"%> logout "& gt;
name="timeout" value="<%= 30 *24 * 60 * 60 %>" 30天
内有效
"<%= Integer.MAX_VALUE %>"> 永久有效
<% } %>
ログイン時にログイン情報の有効期間を選択できます。ブラウザを閉じると期限切れになるか、30 日以内に有効になるか、永久に有効になります。これは、Cookie の age 属性を設定することで実現されます。コードに注意してください。ランニング効果を図 1.7 に示します。
図 1.7 永続ログイン
ヒント: この暗号化メカニズムの最も重要な部分は、アルゴリズムとキーです。 MD1 アルゴリズムの不可逆性により、ユーザーがアカウント番号と暗号化された文字列を知っていたとしても、復号化してキーを取得することは不可能です。したがって、鍵とアルゴリズムが保持されている限り、このメカニズムは安全です。
1.2 セッションメカニズム
セッションは、Cookie の使用に加えて、クライアントのステータスを記録するために Web アプリケーションでよく使用されます。 セッションは、サーバーがクライアントのステータスを記録するために使用するメカニズムです。それに応じて、サーバーのストレージ負荷も増加します。
1.2.1 セッションとは
セッションはクライアントのステータスを記録するための別のメカニズムですが、違いは、Cookie がクライアントのブラウザーに保存されるのに対し、セッションはサーバーに保存されることです。クライアントのブラウザがサーバーにアクセスすると、サーバーはクライアントの情報を何らかの形式でサーバーに記録します。セッションです。 クライアントのブラウザが再度アクセスするときは、セッションから顧客のステータスを見つけるだけで済みます。
Cookieメカニズムが顧客の「パスポート」をチェックすることによって顧客の身元を判断する場合、セッションメカニズムはサーバー上の「顧客の詳細」をチェックすることによって顧客の身元を確認します。セッションは、サーバー上のプログラムによって作成された顧客ファイルに相当します。顧客が訪問したとき、顧客は顧客ファイル テーブルをクエリするだけで済みます。
1.2.2 ユーザーログインを実装するには
Session に対応するクラスは javax.servlet.http.HttpSession クラスです。各訪問者は Session オブジェクトに対応し、すべての顧客のステータス情報はこの Session オブジェクトに保存されます。 Session オブジェクトは、クライアントが最初にサーバーをリクエストしたときに作成されます。 Session はキーと値の属性ペアでもあり、getAttribute(Stringkey) メソッドと setAttribute(String key, Objectvalue) メソッドを通じて顧客ステータス情報を読み書きします。サーブレットでは、request.getSession() メソッドを通じて顧客のセッションを取得します。例:
HttpSession session = request.getSession(); // セッション オブジェクトを取得します
session.setAttribute("loginTime", new) Date()) ; // セッションに属性を設定します
out.println("ログイン時刻は: " +(Date)session.getAttribute("loginTime")); // セッション属性を取得します
リクエストでは、getSession(boolean create) を使用してセッションを取得することもできます。違いは、クライアントのセッションが存在しない場合、request.getSession() メソッドは null を返すのに対し、getSession(true) は最初にセッションを作成してからセッションを返すことです。 HttpSession オブジェクトをプログラムで取得するには、
Request をサーブレットで使用する必要があります。Session の隠しオブジェクトは JSP に組み込まれており、直接使用できます。 <%@page session="false" %> が宣言されている場合、Session 隠しオブジェクトは使用できません。次の例では、Session を使用して顧客アカウント情報を記録します。
ソースコードは次のとおりです:
Code 1.9 session.jsp
<%@ page language="java" pageEncoding="UTF-8"%>
<%!
DateFormat dateFormat = newSimpleDateFormat("yyyy-MM-dd"); //日付の形式 デバイス
%>
<%
response.setCharacterEncoding("UTF-8"); // リクエストのエンコーディングを設定します
person[] people =
{ // 基本データ、3 人の情報を保存p 新しい人 ("liu jinghua", "password1", 34, dateformat.parse
("1982-01-01"),
新しい人 ("ハローキティ", "ハローキティ", 23, DateFormatat .parse
( "1984-02-21"))、（ "garfield"、 "garfield_pass"、23、dateformat.parse //表示されるメッセージ
if（request.getMethod（）。equals（ "post"）） , アカウント、パスワードを確認します
// ユーザー名とパスワードが正しい場合
(person.getName (). EQUALSIGNORECASE (Request.getparameter ("Username") && & Person.getPassword (). st. getparameter (" パスワード")))
// ログイン中の人物を保存します
("Logintime", New Date ()) // ログイン時間を保存します
response.SendRedirect (request.getContextPath () + "/ welcome.jsp") ;
️ PUBLIC "-//W3C//DTD HTML 4.01Transitional//EN">
// ...HTML コードは FORM 形式です。コードは省略されています。付属の CD を参照してください。ログイン インターフェイス ユーザーのログイン情報が正しい場合は、ユーザー情報とログイン時間をセッションに保存し、ウェルカム ページ welcome.jsp に移動します。 Welcome.jsp は、Session から情報を取得し、ユーザー情報を表示します。
welcome.jsp コードは次のとおりです:
コード 1.10 welcome.jsp
<%@ page language="java" pageEncoding="UTF-8"%>
DateloginTime =(Date)session.getAttribute("loginTime"); // ログイン時刻を取得します
%>
// ... 一部HTMLコードを省略しています
;td>あなたの名前:
td>
図 1.8 Session を使用してユーザー情報を記録する
なお、Person クラスのオブジェクトと Date クラスのオブジェクトは、プログラム内の Session に直接保存されるため、Cookie よりも便利に使用できます。
複数のクライアントがプログラムを実行すると、サーバーは複数のクライアントのセッションを保存します。セッションを取得する場合、誰のセッションを取得するかを宣言する必要はありません。 セッションメカニズムは、現在のクライアントが自分のセッションのみを取得し、他の人のセッションを取得しないことを決定します。各クライアントのセッションも互いに独立しており、お互いには見えません。
ヒント: セッションはCookieよりも使いやすいですが、サーバーのメモリに保存されるセッションが多すぎるため、サーバーに負荷がかかります。
1.2.3 セッションのライフサイクル
セッションはサーバー側に保存されます。 より高速なアクセス速度を得るために、サーバーは通常、セッションをメモリに保存します。各ユーザーは独立したセッションを持ちます。セッションの内容が複雑すぎると、多数のクライアントがサーバーにアクセスしたときにメモリ オーバーフローが発生する可能性があります。したがって、セッション内の情報はできる限り簡潔にする必要があります。ユーザーが初めてサーバーにアクセスすると、
セッションが自動的に作成されます。セッションは、JSP、サーブレット、およびその他のプログラムにアクセスする場合にのみ作成されます。HTML や IMAGE などの静的リソースにアクセスする場合のみ、セッションは作成されません。セッションがまだ生成されていない場合は、request.getSession(true) を使用してセッションを強制的に生成することもできます。
Sセッション生成後、ユーザーがアクセスし続ける限り、サーバーはセッションの最終アクセス時刻を更新し、セッションを維持します。 ユーザーがサーバーにアクセスするたびに、セッションの読み取りまたは書き込みに関係なく、サーバーはユーザーのセッションが「アクティブ」であると見なされます。
1.2.4 セッションの有効期間
サーバーにアクセスするユーザーが増えるにつれて、セッションの数も増えていきます。 メモリのオーバーフローを防ぐために、サーバーは長期間アクティブでなかったセッションをメモリから削除します。この時間はセッションのタイムアウト時間です。タイムアウト期間が経過してもサーバーにアクセスしない場合、セッションは自動的に期限切れになります。
Session のタイムアウトは maxInactiveInterval 属性であり、対応する getMaxInactiveInterval() を通じて取得でき、setMaxInactiveInterval(longinterval) を通じて変更できます。
セッションタイムアウトはweb.xmlでも変更できます。さらに、セッションの validate() メソッドを呼び出すことによって、セッションを無効にすることができます。
1.2.5 Session
の共通メソッドセッションにはさまざまなメソッドが含まれており、Cookieよりもはるかに便利に使用できます。 Session の共通メソッドを表 1.2 に示します。
表 1.2 HttpSession の共通メソッド
メソッド名 | 説明 |
void setAttribute(String 属性, Object value) | セッションのプロパティを設定します。 value パラメータには任意の Java オブジェクトを指定できます。通常は Java Bean です。値の情報は大きすぎないでください |
String getAttribute(String 属性) | セッション属性を返す |
Enumeration getAttributeNames() | セッション |
| void RemoveAttribute(String 属性) | セッション属性を削除 |
String getId() | セッションのIDを返します。この ID はサーバーによって自動的に作成され、繰り返されることはありません |
long getCreationTime() | セッションの作成日を返します。戻り値の型はlong型で、多くの場合Date型に変換されます。例: Date createTime = new Date(session.get CreationTime()) |
long getLastAccessedTime() | 最後のアクティブ時間を返します。セッション。戻り値の型はlongです |
int getMaxInactiveInterval() | はセッションのタイムアウトを返します。単位は秒です。この時間を過ぎてもアクセスがない場合、サーバーはセッションが無効であるとみなします |
void setMaxInactiveInterval(int Second) | セッションのタイムアウトを設定します。単位は秒です |
void putValue(String属性, Object value) | 非推奨のメソッドです。 setAttribute(Stringattribute,ObjectValue) |
Object getValue(Stringattribute) | 非推奨のメソッドに置き換えられました。 getAttribute(String attr) に置き換えられました |
boolean isNew() | セッションが新しく作成されたかどうかを返します |
void validate() | セッションを無効にする |
Tomcat のデフォルトのセッションタイムアウトは 20 分です。 setMaxInactiveInterval(int 秒) を通じてタイムアウトを変更します。 web.xml を変更して、セッションのデフォルトのタイムアウトを変更できます。たとえば、60 分に変更します。
セッションはサーバーに保存され、クライアントに対して透過的ですが、その通常の動作には依然としてクライアントブラウザのサポートが必要です。これは、Session が識別マークとして Cookie を使用する必要があるためです。 HTTP プロトコルはステートレスであり、セッションは HTTP 接続に基づいて同じクライアントであるかどうかを判断できません。そのため、サーバーは JSESSIONID という名前の Cookie をクライアントのブラウザーに送信します。その値はセッションの ID (つまり、 HttpSession.getId() 戻り値)。セッションはこの Cookie を使用して、同じユーザーであるかどうかを識別します。 そのため、同じマシン上の 2 つのブラウザ ウィンドウがサーバーにアクセスすると、2 つの異なるセッションが生成されます。ただし、ブラウザウィンドウ内のリンクやスクリプト等により新たに開かれるウィンドウ（デスクトップブラウザのアイコンのダブルクリック等により開かれないウィンドウ）は除きます。このタイプの子ウィンドウは親ウィンドウの Cookie を共有するため、セッションを共有します。 注: 新しく開かれたブラウザウィンドウは、子ウィンドウを除き、新しいセッションを生成します。子ウィンドウは親ウィンドウのセッションを共有します。 たとえば、リンクを右クリックしてポップアップショートカットメニューから「新しいウィンドウで開く」を選択すると、子ウィンドウは親ウィンドウのセッションにアクセスできます。 クライアントのブラウザがCookie機能を無効にしている場合、またはCookieをサポートしていない場合はどうすればよいですか?たとえば、モバイル ブラウザの大部分は Cookie をサポートしていません。 Java Web は、URL アドレスの書き換えという別の解決策を提供します。 1.2.7 URLアドレス書き換え
URLアドレス書き換えは、Cookieをサポートしていないクライアントのためのソリューションです。 URL アドレス書き換えの原理は、ユーザーのセッション ID 情報を URL アドレスに書き換えることです。サーバーは、書き換えられた URL を解析してセッション ID を取得できます。このようにして、クライアントが Cookie をサポートしていない場合でも、Session を使用してユーザーのステータスを記録できます。 HttpServletResponse クラスは、URL アドレス書き換えを実装するための encodeURL (Stringurl) を提供します。例: このメソッドは、クライアントが Cookie をサポートしているかどうかを自動的に判断します。クライアントが Cookie をサポートしている場合、URL はそのまま出力されます。クライアントが Cookie をサポートしていない場合、ユーザーのセッション ID が URL に書き換えられます。書き換えられた出力は次のようになる場合があります。 XXX はセッションの ID です。分析の結果、追加された jsessionid 文字列は、要求されたファイル名にも送信されたアドレス バー パラメーターにも影響を及ぼさないことが示されています。ユーザーがこのリンクをクリックすると、セッション ID が URL を通じてサーバーに送信され、サーバーは URL アドレスを解析してセッション ID を取得します。 ページのリダイレクト (Redirection) の場合、URL アドレスの書き換えは次のように記述できます: <% 注: 2回目の訪問時はサーバーがブラウザにCookieを書き込んでいるため、書き換え後のURLアドレスにはjsessionidが含まれません。 1.2.8 セッションでの Cookie の使用は禁止されています WAP 上のほとんどのクライアント ブラウザは Cookie をサポートしていないため、単純にセッションで Cookie を無効にして、一律に URL アドレス書き換えを使用する方がよいでしょう。 Java Web 仕様では、構成による Cookie の無効化がサポートされています。ここでは、設定を通じて Cookie の使用を無効にする方法の例を示します。 プロジェクト sessionWeb の WebRoot ディレクトリにある META-INF フォルダーを開き (WEB-INF フォルダーと同じレベル、存在しない場合は作成します)、context.xml を開きます (存在しない場合は作成します)。コンテンツを次のように編集します: Code 1.11 /META-INF/context.xml < ;/Context> または、Tomcat のグローバル conf/context.xml を次のように変更します: Code 1.12 context.xml