Cookie/セッションの仕組みの詳しい説明_html/css_WEB-ITnose-htmlチュートリアル-php.cn

ホームページ

ウェブフロントエンド

htmlチュートリアル

Cookie/セッションの仕組みの詳しい説明_html/css_WEB-ITnose

WBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWB

Jun 24, 2016 am 11:49 AM

セッション追跡は、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 の内容を変更することもできます。

Web サイトによって発行された 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 も含まれますか?それとも、Baidu が発行した Cookie を Google が変更できるのでしょうか?

答えはノーです。 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 を操作できません。

Webサイトimages.google.comとWebサイト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 が作成されると、その名前は変更できません。オブジェクトの値 Cookie の値。値が Unicode 文字の場合、その文字をエンコードする必要があります。値がバイナリデータの場合は、BASE64 エンコードを使用する必要があります。 boolean secure このCookieが安全なプロトコルを使用してのみ送信されるかどうか。セキュリティプロトコル。セキュリティプロトコルには、ネットワーク上で送信する前にデータを暗号化する HTTPS、SSL などが含まれます。デフォルトは false ですString path この Cookie で使用されるパス。「/sessionWeb/」に設定すると、contextPath が「/sessionWeb」であるプログラムのみが Cookie にアクセスできます。「/」に設定すると、このドメイン名の contextPath によって Cookie にアクセスできます。最後の文字は「/」である必要があることに注意してください。文字列ドメイン Cookie にアクセスできるドメイン名。「.google.com」に設定すると、「google.com」で終わるすべてのドメイン名がこの 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); // クライアントへの出力

maxAge が負の数の場合、Cookie はこのブラウザウィンドウとこのウィンドウによって開かれたサブウィンドウ内でのみ有効であることを意味します。ウィンドウを閉じるとクッキーは無効になります。負の maxAge を持つ Cookie は一時的な Cookie であり、永続化されず、Cookie ファイルに書き込まれません。 Cookie 情報はブラウザのメモリに保存されるため、ブラウザを閉じると Cookie は消えます。 Cookie のデフォルトの maxAge 値は ?1 です。

maxAge が 0 の場合、Cookie が削除されたことを意味します。 Cookie メカニズムには Cookie を削除する方法が用意されていないため、Cookie をすぐに期限切れになるように設定することで、Cookie を削除する効果が得られます。無効な Cookie はブラウザによって Cookie ファイルまたはメモリから削除されます。

例:

Cookie cookie = new Cookie("username","helloweenvsfei") // 新しい Cookie を作成します

cookie.setMaxAge (0) ;

Cookie を変更したい場合は、変更の目的を達成するために、同じ名前の Cookie を使用して元の Cookie を上書きする必要があります。削除する場合は、maxAge を 0 に変更するだけです。

注: クライアントから Cookie を読み取るとき、maxAge を含む他の属性は読み取ることができないため、送信されません。ブラウザが Cookie を送信する場合、名前と値の属性のみが送信されます。 maxAge 属性は、Cookie の有効期限が切れているかどうかを判断するためにブラウザによってのみ使用されます。

1.1.8 Cookie の変更と削除

Cookie は変更または削除の操作を提供しません。 Cookie を変更する場合は、同じ名前で新しい Cookie を作成し、それを応答に追加して元の Cookie を上書きするだけです。

Cookie を削除したい場合は、同じ名前で新しい Cookie を作成し、maxAge を 0 に設定し、それをレスポンスに追加して元の Cookie を上書きするだけです。これは 0 であり、負の数ではないことに注意してください。負の数は他の意味を表します。読者は、上記の例のプログラムを通じてさまざまな属性を確認および設定できます。

注: Cookie を変更または削除する場合、名前、パス、ドメインなど、新しく作成された Cookie の value と 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 名の下にあるすべてのセカンダリドメイン名でこの Cookie を使用できるようにするには、Cookie のドメインパラメータを設定する必要があります。例: Cookie cookie = new Cookie("time","20080808") ); // 新しい cookie を作成します

cookie.setDomain(".helloweenvsfei.com"); // ドメイン名を設定します

cookie.setPath("/"); // 有効期間を設定します

response (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 を作成します

cookie.setSecure(true); (cookie); // クライアントへの出力

注: Secure プロパティは Cookie の内容を暗号化しないため、絶対的なセキュリティを保証することはできません。高いセキュリティが必要な場合は、

漏洩を防ぐためにプログラム内でCookieの内容を暗号化および復号化する必要があります。

1.1.12 JavaScriptはCookieを操作します

Cookieはブラウザ側に保存されるため、ブラウザはCookieを操作するための前提条件を備えています。ブラウザは JavaScript や VBScript などのスクリプトプログラムを使用して Cookie を操作できます。ここでは、JavaScript を例として、一般的に使用される Cookie の操作を紹介します。たとえば、次のコードはこのページのすべての Cookie を出力します。

1.1.13 ケース: 永久ログイン

ユーザーが自宅のコンピューターでインターネットサーフィンをしている場合、ログイン時にそのログイン情報を記憶できます。次回訪問するときに再度ログインする必要はありません。直接アクセスしてください。実装方法は、アカウント番号やパスワードなどのログイン情報をCookieに保存し、Cookieの有効期限を管理し、次回訪問時にCookie内のログイン情報を確認する方法です。

ログイン情報を保存するには多くのオプションがあります。最も直接的なのは、ユーザー名とパスワードを Cookie に保存し、次回アクセスしたときに Cookie 内のユーザー名とパスワードを確認し、データベースと比較することです。これは危険な選択です。通常、パスワードなどの重要な情報は Cookie に保存されません。

別の解決策

は、パスワードを暗号化して Cookie に保存し、次回のアクセス時に復号化してデータベースと比較することです。この解決策は若干安全です。パスワードを保存したくない場合は、ログインタイムスタンプを Cookie とデータベースに保存し、ユーザー名とログインタイムスタンプのみを検証することもできます。

これらのスキームはすべて、アカウントを確認するときにデータベースにクエリを実行する必要があります。

この例では、ログイン時に 1 回だけデータベースにクエリを実行し、今後ログイン情報を確認するためにアクセスするときにデータベースにクエリを実行しない別のソリューションを使用します。これを実現する方法は、特定のルールに従ってアカウントを暗号化し、アカウントと一緒に Cookie に保存することです。次回アクセスするときは、アカウントの暗号化ルールが正しいかどうかを判断するだけで済みます。この例では、アカウントは account という名前の Cookie に保存され、アカウントとキーは MD1 アルゴリズムを使用して暗号化されてから、ssid という名前の Cookie に保存されます。検証中に、Cookie 内の暗号化されたアカウント番号とキーが Cookie 内の SSID と等しいかどうかを検証します。関連するコードは次のとおりです。

Code 1.8 loginCookie.jsp

<%@ page language="java"pageEncoding="UTF-8" isErrorPage="false" %>

<%!メソッド

private static Final String KEY =":cookie@helloweenvsfei.com";

String s = ==null ?"" : ss // null が空を返す場合

CHAR Hexdigitals [] = {'0', '1'、'2'、'3'、'4'、'1'、'6'、'8'、'8'、'9'、

'a'、'b'、'c'、' d '、' F '} null; }

}

% >

request.setCharacterEncoding("UTF-8") // リクエストのエンコーディングを設定します

response.setCharacterEncoding("UTF-8");レスポンスエンコーディング

String action = request.getParameter("action") // アクションパラメータを取得します

;if（ "login" .equals（action））{'' s '' '' '' '' '' '' 'out out's out out out out out out out out out out out out out Outオーバーの ‐ ‐‐‐‐‐‐‐‐ ‐‐ ‐‐ ‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐ ");

// パスワードパラメータを取得します

int Timeout = Newinteger (request.getparameter (" "timeout"); + Key) // 、キーは MD1 を使用して暗号化され、保存されます

CookieaccountCookie = new Cookie("アカウント", ' s ' ' ' ' ' ' ' ' ' それ 1 それはそれはそれはその前にそれは ' s ' ' i ' t ' ti

の間// 新しい Cookie を作成します

ssid; Cookie.setMaxAge(timeout); // クライアントに出力

response.addCookie(ssidCookie ;

currentTimeMillis()); Cookie("account", ""); // 新しい Cookie、中身は空です
accountcookie.setmaxage (0) // 設定期間は 0、削除します

("" "" SSID "," "); // 新しい Cookie、コンテンツは空です

ssidCookie.setMaxAge(0);応答.addCookie(ssidCookie); // クライアントに出力します

本 // ブラウザのキャッシュページコンテンツを禁止するパラメータにタイムスタンプを付けてこのページを再リクエストします

response.Sendredirect (request.getRequesturi () + "?" + System.

CurrenTtimemillis ()

}
; Boolean login = false // ログインするかどうか

String account = null; // アカウント

string ssid = null;

ll) {{ // Cookie が空でない場合

account U o academ = cookie.getValue () // コンテンツ content を保存します

IF (cookie.getName (). Equals ("ssid")) // SSID content

}

if(account != null && ssid !=null){ // アカウントも SSID も空でない場合

//暗号化ルールが正しければログインしたものとみなされます

}

;<%= ログイン ? "ようこそ" : "まずログインしてください"%

< ;formaction="${ pageContext. request.requesturi}？action = login "gt;

tr＆gt; password：＆lt;/td＆gt;

チェック済み
入力タイプ = "ラジオ"

名前 = "タイムアウト" 値 = "& lt; %= 30*24*60 %& gt; = "ラジオ "name =" timeout "value =

。lt; td＆gt;＆lt;/td＆gt;これは、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) ()) ; // Session に属性を設定します

out.println("Login time is: " +(Date)session.getAttribute("loginTime")) // セッション属性を取得します

リクエストは getSession も使用できます(boolean create) を使用してセッションを取得します。違いは、クライアントのセッションが存在しない場合、request.getSession() メソッドは null を返すのに対し、getSession(true) は最初にセッションを作成してからセッションを返すことです。

HttpSession オブジェクトをプログラムで取得するには、Servlet で 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人のデータ情報

through using using using using using out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out out）

文字列メッセージ = " "; 人)

{

// 基本データをスキャンし、アカウント番号、パスワードを確認します

// ユーザー名とパスワードが正しい場合

。息子 .getPassword().equals(request.getParameter( 「パスワード」)))

session.setAttribute("person", person) ; リダイレクト(request.getContextPath() + "/welcome.jsp");

return; "; // ログインに失敗しました

🎜 }🎜 🎜%>🎜 🎜🎜 🎜🎜 🎜 // . .. HTML コードは FORM 形式です。コードは省略されています。付属の CD を参照してください 🎜 🎜🎜 🎜 🎜

ログインインターフェイスはユーザーのログイン情報を検証し、ログインが正しければ、ユーザー情報とログイン時間がセッションに保存され、ウェルカムページ welcome.jsp に移動します。 Welcome.jsp は、Session から情報を取得し、ユーザー情報を表示します。

welcome.jsp コードは次のとおりです:

コード 1.10 welcome.jsp

<%@ page language="java" pageEncoding="UTF-8"%>

& lt;%

person person = (person) session.getattribute ("" person ") // Logintime " ); ; d> ;あなたの名前:

;

= person.getage（）％＆gt;＆lt;/td＆gt;

図 1.8 Session を使用してユーザー情報を記録する

なお、Person クラスのオブジェクトと Date クラスのオブジェクトは、プログラム内の Session に直接保存されるため、Cookie よりも便利に使用できます。

複数のクライアントがプログラムを実行すると、サーバーは複数のクライアントのセッションを保存します。セッションを取得する場合、誰のセッションを取得するかを宣言する必要はありません。

セッションメカニズムは、現在のクライアントが自分のセッションのみを取得し、他の人のセッションを取得しないことを決定します。各クライアントのセッションも互いに独立しており、お互いには見えません

。

ヒント

: セッションは Cookie よりも使いやすいですが、サーバーのメモリに保存されるセッションが多すぎるとサーバーに負荷がかかります。

1.2.3 セッションのライフサイクル

セッションはサーバー側に保存されます。

より高速なアクセス速度を得るために、サーバーは通常、セッションをメモリに保存します。各ユーザーは独立したセッションを持ちます。セッションの内容が複雑すぎると、多数のクライアントがサーバーにアクセスしたときにメモリオーバーフローが発生する可能性があります。したがって、セッション内の情報はできる限り簡潔にする必要があります。

セッションは、ユーザーが初めてサーバーにアクセスするときに自動的に作成されます

。セッションは、JSP、サーブレット、およびその他のプログラムにアクセスする場合にのみ作成されます。HTML や IMAGE などの静的リソースにアクセスする場合のみ、セッションは作成されません。セッションがまだ生成されていない場合は、request.getSession(true) を使用してセッションを強制的に生成することもできます。

セッション生成後、ユーザーがアクセスし続ける限り、サーバーはセッションの最終アクセス時刻を更新し、セッションを維持します。ユーザーがサーバーにアクセスするたびに、セッションの読み取りまたは書き込みに関係なく、サーバーはユーザーのセッションが「アクティブ」であるとみなします。

1.2.4 セッションの有効期間

サーバーにアクセスするユーザーが増えるにつれて、セッションの数も増えていきます。メモリのオーバーフローを防ぐために、サーバーは長期間アクティブでなかったセッションをメモリから削除します。この時間はセッションのタイムアウト時間です。タイムアウト期間が経過してもサーバーにアクセスしない場合、セッションは自動的に期限切れになります。

セッションのタイムアウト時間は maxInactiveInterval 属性であり、対応する getMaxInactiveInterval() を通じて取得でき、setMaxInactiveInterval(longinterval) を通じて変更できます。

セッションタイムアウトはweb.xmlでも変更できます。さらに、セッションの validate() メソッドを呼び出すことによって、セッションを無効にすることができます。

1.2.5 Session の共通メソッド

Session には Cookie よりもはるかに便利なさまざまなメソッドが含まれています。 Session の共通メソッドを表 1.2 に示します。

表 1.2 HttpSession の共通メソッド

属性プロパティ名	説明
文字列名

int maxAge	Cookie の有効期限が切れるまでの時間 (秒単位)。正の場合、Cookie は maxAge 秒後に期限切れになります。負の数の場合、Cookie は一時的な Cookie であり、ブラウザを閉じると無効になり、ブラウザはいかなる形式でも Cookie を保存しません。 0の場合はCookieを削除することを意味します。デフォルトは?1です。



		<%= person.getName()%>

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(String Attribute, Object Value)Object getValue(String Attribute)非推奨のメソッドに置き換えられました。 getAttribute(String attr) に置き換えられましたboolean isNew()セッションが新しく作成されたかどうかを返しますvoid validate()セッションを無効にする

Tomcat のデフォルトのセッションタイムアウトは 20 分です。 setMaxInactiveInterval(int 秒) を通じてタイムアウトを変更します。 web.xml を変更して、セッションのデフォルトのタイムアウトを変更できます。たとえば、60 分に変更します。

注: パラメータの単位は次のとおりです。 setMaxInactiveInterval(int s) の単位は秒です。

1.2.6 ブラウザのセッション要件

セッションはサーバーに保存され、クライアントに対して透過的ですが、その通常の動作にはクライアントブラウザのサポートが必要です。これは、Session が識別マークとして Cookie を使用する必要があるためです。 HTTP プロトコルはステートレスであり、セッションは HTTP 接続に基づいて同じクライアントであるかどうかを判断できません。そのため、サーバーは JSESSIONID という名前の Cookie をクライアントのブラウザーに送信します。その値はセッションの ID (つまり、 HttpSession.getId() 戻り値)。セッションはこの Cookie を使用して、同じユーザーであるかどうかを識別します。

この Cookie はサーバーによって自動的に生成され、その maxAge 属性は通常 ?1 です。これは、現在のブラウザー内でのみ有効であり、ブラウザーウィンドウ間で共有されないことを意味します。

そのため、同じマシン上の 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 に書き換えられます。書き換えられた出力は次のようになります。

メソッド名	説明
void setAttribute(String 属性, Object value)	セッションのプロパティを設定します。 value パラメータには任意の Java オブジェクトを指定できます。通常は Java Bean です。値の情報は大きすぎてはなりません
String getAttribute(String 属性)	セッション属性を返す










		"> ホームページ	1&wd=Java">Homepage < /td> つまり、文字列「;jsessionid=XXX」がファイル名の後ろと URL パラメータの前に追加されます。 XXX はセッションの ID です。分析の結果、追加された jsessionid 文字列は、要求されたファイル名にも、送信されたアドレスバーパラメーターにも影響を及ぼさないことが示されています。ユーザーがこのリンクをクリックすると、セッション ID が URL を通じてサーバーに送信され、サーバーは URL アドレスを解析してセッション ID を取得します。ページのリダイレクト (Redirection) の場合、URL アドレスの書き換えは次のように記述できます: <% if("administrator".equals(userName)) { response.sendRedirect(response) .encodeRedirectURL( "administrator.jsp")); return; 、書き換えられたアドレスを jsessionid 文字列で返します。 WAP プログラムの場合、ほとんどのモバイルブラウザは Cookie をサポートしていないため、WAP プログラムは URL アドレスの書き換えを使用してユーザーセッションを追跡します。たとえば、UFIDA グループのモバイルショッピングモール。注: TOMCAT は、リクエストに Cookie が含まれるかどうかに基づいて、クライアントのブラウザが Cookie をサポートするかどうかを判断します。クライアントは Cookie をサポートしている可能性がありますが、最初のリクエストでは Cookie が送信されないため (送信する Cookie がないため)、書き換えられた URL アドレスには jsessionid が含まれたままになります。 2回目のアクセス時はサーバーがブラウザにCookieを書き込んでいるため、書き換え後のURLアドレスにはjsessionidは含まれません。 1.2.8 Session での Cookie の使用は禁止されています WAP 上のほとんどのクライアントブラウザは Cookie をサポートしていないため、単純に Session での 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 展開後、TOMCAT は JSESSIONID Cookie という名前を自動的に生成しません。Session は Cookie を識別マークとして使用せず、書き換えられた URL アドレスのみを識別マークとして使用します。注: この設定は、セッションが識別マークとして Cookie を使用することを禁止するだけであり、他の Cookie の読み取りと書き込みは妨げられません。つまり、サーバーは JSESSIONID という名前の Cookie を自動的に維持しませんが、他の Cookie は引き続きプログラムで読み書きできます。 http://blog.csdn.net/fangaoxin/article/details/6952954