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 を出力します。
<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 と等しいかどうかを検証します。関連するコードは次のとおりです。
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 も空でない場合
Login =ssid.equals(calcMD1(account + KEY));
//暗号化ルールが正しければログインしたものとみなされます
}
%>
;<%= ログイン ? "ようこそ" : "まずログインしてください"%
< ;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.getName()%> |
;
= 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 の共通メソッド
| メソッド名 | 説明 |
| 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(String Attribute, Object Value) |
Object getValue(String Attribute)| | 非推奨のメソッドに置き換えられました。 getAttribute(String attr) に置き換えられました |
boolean isNew()| | セッションが新しく作成されたかどうかを返します |
void validate()| | セッションを無効にする |
Tomcat のデフォルトのセッションタイムアウトは 20 分です。 setMaxInactiveInterval(int 秒) を通じてタイムアウトを変更します。 web.xml を変更して、セッションのデフォルトのタイムアウトを変更できます。たとえば、60 分に変更します。
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 に書き換えられます。書き換えられた出力は次のようになります。
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 |
