Cookieとセッションの比較

1. Cookieメカニズムとセッションメカニズムの違い

具体的には、Cookie機構はクライアント側で状態を保持するソリューションを採用し、セッション機構はサーバー側で状態を保持するソリューションを採用します。
同時に、サーバー側で状態を維持するソリューションではクライアント側でも ID を保存する必要があるため、セッション メカニズムでは ID を保存するという目的を達成するために Cookie メカニズムを使用する必要があることもわかります。しかし実際には他の選択肢もあります。
2. セッション Cookie と永続的な Cookie の違い
有効期限が設定されていない場合、この Cookie のライフサイクルはブラウザ ウィンドウが閉じている限り消滅します。ブラウジング セッション中に持続するこのような Cookie は、セッション Cookie と呼ばれます。セッション Cookie は通常、ハードディスクではなくメモリに保存されます。
有効期限が設定されている場合、ブラウザは Cookie をハードドライブに保存します。ブラウザを閉じて再度開いた場合、これらの Cookie は設定された有効期限を超えるまで有効です。
ハードドライブに保存されたCookieは、2つのIEウィンドウなど、異なるブラウザプロセス間で共有できます。ブラウザーが異なれば、メモリに保存された Cookie を処理する方法も異なります。
3. 自動ログインの使用方法
ユーザーが Web サイトに登録すると、固有のユーザー ID を持つ Cookie を受け取ります。後でクライアントが再接続すると、このユーザー ID が自動的に返され、サーバーはそれが自動ログインが選択された登録ユーザーであるかどうかを確認して、ユーザーが明示的なユーザー名とパスワードを指定しなくてもサーバー上のリソースにアクセスできるようにします。
4. ユーザーの好みに応じてサイトをカスタマイズする方法
ウェブサイトはユーザーの要望を記録するために Cookie を使用することがあります。簡単な設定の場合、Web サイトはページ設定を Cookie に直接保存してカスタマイズを完了できます。ただし、より複雑なカスタマイズの場合、Web サイトは一意の識別子をユーザーに送信するだけで済み、サーバー側のデータベースには各識別子に対応するページ設定が保存されます。
5. Cookie を送信する
1. Cookie オブジェクトを作成する
2. 最大有効期限を設定する
Cookie を作成してブラウザに送信する場合、デフォルトでは A セッションになります。 -レベル Cookie: ブラウザのメモリに保存され、ユーザーがブラウザを終了すると削除されます。ブラウザに Cookie をディスクに保存させたい場合は、maxAge を使用して時間を秒単位で指定する必要があります。最大存続期間を 0 に設定すると、ブラウザーに Cookie を削除するように指示されます。
Cookieを送信するには、HttpServletResponseのaddCookieメソッドを使用して、Set-Cookie HTTPリクエストヘッダーにCookieを挿入する必要があります。このメソッドは、以前に指定された Set-Cookie ヘッダーを変更せず、新しいヘッダーを作成するため、このメソッドを setCookie の代わりに addCookie と呼びます。また、ドキュメントのコンテンツをクライアントに送信する前に、応答ヘッダーを設定する必要があることにも注意してください。
6. Cookie の読み取り
1. request.getCookie を呼び出す
ブラウザーによって送信された Cookie を取得するには、HttpServletRequest の getCookies メソッドを呼び出す必要があります。この呼び出しは、Cookie ヘッダーによって入力された値に対応する Cookie オブジェクトの配列を返します。 HTTP リクエスト内。
2. 配列をループし、目的の Cookie が見つかるまで各 Cookie の getName メソッドを呼び出します
Cookie はサーブレットや JSP ページではなく、ホスト (ドメイン) に関連しています。したがって、サーブレットは 1 つの Cookie しか送信しない場合でも、無関係な Cookie を多数受信する可能性があります。
例:
String cookieName = “userID”;
Cookie cookies［] = request.getCookies();
if (cookies!=null){
for(int i=0;i
Cookie cookie = cookies［i］ ;
if (cookieName.equals(cookie.getName())){
doSomethingWith(cookie.getValue());
}
}
}
7. Cookie を使用して初回訪問者を検出する方法
A. .getCookies() Cookie 配列を取得します
B. 指定された名前の Cookie が存在するかどうか、および対応する値が正しいかどうかを取得します
C. 存在する場合は、ループを終了して識別識別子を設定します
D.識別識別子に基づいてユーザーは初めての訪問者であると判断し、違いを生む 操作
8. Cookie を使用して初回訪問者を検出する際のよくある間違い
特定のデータ項目だけを理由にユーザーが初めての訪問者であると考えることはできませんcookie 配列に が存在しない場合、顧客は初めての訪問者である可能性があります
ただし、配列が null でない場合は、これは、顧客が Web サイトまたはドメインにアクセスしたことを示すだけであり、他の JSP ページや非 Java Web アプリケーションにアクセスしたことを意味するものではありません。パス設定によっては、任意の Cookie が返される可能性があります。正しいアプローチは、Cookie 配列が空かどうか、および指定された Cookie オブジェクトが存在するかどうかを判断することです。
9. Cookie 属性の使用に関する注意事項
属性はサーバーからブラウザーに送信されるヘッダーの一部です。 ; ただし、これらはブラウザーからサーバーに返されるヘッダーの一部ではありません。したがって、名前と値に加えて、Cookie 属性はサーバーからクライアントの Cookie に出力される場合にのみ適用されます。サーバー側からはこれらの属性が設定されていません
したがって、request.getCookies を通じて取得した Cookie でこの属性を使用することは期待しないでください。これは、Cookie の最大有効期間を設定し、それを発行し、後続の入力配列で適切な Cookie を探し、その値を読み取り、変更して Cookie に保存するだけでは、Cookie 値の変更を実装できないことを意味します。 。
10. Cookie を使用して各ユーザーのアクセス数を記録する方法
1. ユーザーの訪問数をカウントするために使用される Cookie の値を取得します
2. 値を int 型に変換します
3. . 値に 1 を加えて元の名前を使用します Cookie オブジェクトを再作成します
4. 最大エージングをリセットします
11. 異なる環境でのセッションの異なる意味
セッション、中国語では次のように翻訳されることがよくあります。本来の意味は「始まり」と「終わり」を意味し、電話をかけるなどの一連の動作・メッセージのことを指し、電話を取り、ダイヤルし、電話を切るまでの一連の処理を指します。セッション。
ただし、セッションという言葉がネットワークプロトコルに関連付けられている場合、多くの場合、「接続指向」および/または「状態の維持」という2つの意味が暗示されます。
Web開発環境におけるセッションのセマンティクスは拡張されており、その意味はクライアントとサーバーの間で状態を維持するために使用されるソリューションの一種を指します。場合によっては、セッションは、このソリューションのストレージ構造を参照するためにも使用されます。
12. セッションメカニズム
セッションメカニズムは、サーバー側のメカニズムであり、ハッシュテーブルに似た構造を使用して情報を保存します。
しかし、プログラムがクライアントのリクエストに対してセッションを作成する必要がある場合、サーバーはまずクライアントのリクエストにセッションIDと呼ばれるセッション識別子が含まれているかどうかを確認します。セッションIDがすでに含まれている場合、それはこのクライアント用に作成されたことを意味します。セッションを渡した後、サーバーはセッション ID に従ってセッションを取得し、それを使用します (取得できない場合は、新しいセッションを作成する可能性があります。この状況は、サーバーがセッション ID に対応するセッション オブジェクトを削除した場合に発生する可能性があります。ユーザーですが、ユーザーは要求された JSESSION パラメーターを人為的に追加しました)。
クライアントリクエストにセッションIDが含まれていない場合、このクライアント用にセッションが作成され、このセッションに関連付けられたセッションIDがこのレスポンスに保存するためにクライアントに返されます。
13. セッション ID を保存するいくつかの方法
A.セッション ID は Cookie を使用して保存できるため、対話中にブラウザはルールに従ってこの ID をサーバーに自動的に送信できます。
B. Cookie は人為的に無効にできるため、Cookie が無効になっている場合でもセッション ID をサーバーに返すための他のメカニズムが必要です。よく使用される手法は、URL の末尾にセッション ID を追加する URL 書き換えと呼ばれます。パスを追加するには 2 つの方法があり、1 つは URL パスに追加情報として追加する方法、もう 1 つは URL の末尾に追加するクエリ文字列として追加する方法です。ネットワークは対話全体を通して状態を維持し、このセッション ID はクライアントが要求するすべてのパスの最後に含める必要があります。
C.もう 1 つの手法は、フォーム非表示フィールドと呼ばれます。つまり、サーバーは自動的にフォームを変更し、非表示フィールドを追加して、フォームの送信時にセッション ID をサーバーに返すことができるようにします。
14. セッションはいつ作成されますか? よくある間違いは、クライアントがアクセスしたときにセッションが作成されると考えることですが、実際には、サーバー側のプログラム (サーブレットなど) がそのようなステートメントを呼び出すまでは作成されません。 HttpServletRequest.getSession(true) が作成されます。
15. セッションはいつ削除されますか?
次の状況でセッションが削除されます:
A.プログラムは HttpSession.invalidate() を呼び出します
B．クライアントによって送信された最後のセッション ID からの時間間隔がセッションの最大有効時間を超えています
C。サーバー プロセスが停止します
ブラウザを閉じると、クライアント ブラウザのメモリに保存されているセッション Cookie が無効になるだけで、サーバー側のセッション オブジェクトは無効になりません。
16. URL 書き換えのデメリットは何ですか
ハイパーリンク、フォーム アクション、リダイレクトされた URL を含むすべての URL に URL 書き換えを使用します。サイトを参照する各 URL、およびユーザーに返される URL (サーバー リダイレクトの Location フィールドなどの間接的な手段を介した場合でも) には、追加情報が追加されます。
これは、サイト上に静的 HTML ページを含めることができないことを意味します (少なくとも、静的ページにはサイト上の動的ページへのリンクを含めることはできません)。したがって、各ページはサーブレットまたは JSP を使用して動的に生成する必要があります。すべてのページが動的に生成された場合でも、ユーザーがセッションを離れ、ブックマークやリンクを介して再び戻ってきた場合、保存されたリンクに誤った識別情報が含まれているため、セッション情報は失われます。つまり、URL の背後にある SESSION ID の有効期限が切れています。
17. 非表示のフォームフィールドを使用するデメリットは何ですか?
この方法は、各ページがフォーム送信によって動的に生成される場合にのみ使用できます。通常のハイパーテキスト リンクをクリックしてもフォーム送信は生成されないため、非表示のフォーム フィールドは通常のセッション追跡をサポートできず、オンライン ストアのチェックアウト プロセスなどの一連の特定の操作でのみ使用できます。
1.現在のリクエストに関連するセッション オブジェクトにアクセスします
2.会話関連の情報を見つける
3．ストアセッション情報
4.セッションデータを破棄
19. getSession()/getSession(true)とgetSession(false)の違い
getSession()/getSession(true): セッションが存在する場合はセッションを返し、それ以外の場合は新しいセッションを作成してオブジェクトを返します
getSession (false): セッションが存在する場合はセッションを返します。それ以外の場合、セッションは作成されず、null が返されます。 replace 値を削除するには、removeAttribute を使用する必要があります。このメソッドは、HttpSessionBindingListener インターフェイスを実装するすべての値の valueUnbound メソッドをトリガーします。
21. セッション属性のタイプに制限はありますか? 通常、セッション属性のタイプはオブジェクトである必要があります。 null または int、double、boolean などの基本型を除きます。
基本型の値を属性として使用したい場合は、対応するカプセル化されたクラスオブジェクトに変換する必要があります
22.セッションデータの破棄方法
A.自分が作成したサーブレットによって作成されたデータのみを削除します:
removeAttribute("key") を呼び出して、指定されたキーに関連付けられた値を破棄します
B。セッション全体を削除します (現在の Web アプリケーション内):
セッション全体を破棄するには、invalidate を呼び出します。そうすると、サーブレットや JSP ページ
C によって作成されたセッション データだけでなく、そのユーザーのすべてのセッション データが失われます。ユーザーをシステムからログアウトし、そのユーザーに属するすべてのセッションを削除します。
logOut を呼び出して、Web サーバーからクライアントをログアウトし、ユーザーに関連付けられたすべてのセッションを破棄します (Web アプリケーションごとに最大 1 つ)。この操作は、サーバー上の複数の異なる Web アプリケーションに影響を与える可能性があります。
23. ユーザーが新しいユーザーか古いユーザーかを判断するために isNew を使用する間違った方法
public boolean isNew() メソッド セッションがクライアント プログラム (ブラウザー) とまだ接続していない場合、このメソッドは true を返します。これは通常、セッションが新規であるためであり、顧客からのリクエストが原因ではありません。
ただし、isNew が false を返した場合、それはユーザーが以前に Web アプリケーションにアクセスしたことがあるというだけで、サーブレットや JSP ページにアクセスしたことがあるという意味ではありません。
セッションはユーザーに関連しているため、ユーザーが以前にアクセスしたすべてのページでセッションが作成されている可能性があります。したがって、isNew が false の場合は、ユーザーが以前に Web アプリケーションにアクセスしたことがあるということのみを意味し、現在のページまたはユーザーが以前にアクセスしたことのあるページによってセッションを作成できます。
正しいアプローチは、特定のキーがセッションに存在するかどうか、そしてその値が正しいかどうかを判断することです
24. Cookie の有効期限とセッション タイムアウトの違いは何ですか? セッション タイムアウトは、Cookie の有効期限とは異なり、サーバーによって維持されます。日付。まず、セッションは通常、メモリ常駐 Cookie に基づいていますが、これは永続的な Cookie ではないため、有効期限がありません。 JSESSIONID Cookie が傍受された場合でも、有効期限が設定されて送信されます。ブラウザ セッションとサーバー セッションは大きく異なる場合もあります。
25. セッション Cookie とセッション オブジェクトのライフ サイクルは同じですか?
ユーザーがブラウザを閉じると、セッション Cookie は消えても、セッション オブジェクトはサーバー側に保存されますか?
26.ブラウザが閉じられたら消えます
通常、プログラムはユーザーがログオフするときにセッションを削除する命令を送信しますが、ブラウザは閉じる前にセッションが閉じることを積極的に通知することはないため、サーバーはそれを知ることができません。ブラウザが閉じられました。サーバーは、設定された期間非アクティブになるまで、このセッション オブジェクトを保持します。
この誤解の理由は、ほとんどのセッションメカニズムがセッション ID を保存するためにセッション Cookie を使用するため、ブラウザを閉じるとセッション ID が消え、サーバーに再度接続すると元のセッションが見つからなくなるためです。
サーバーによって設定された Cookie がハードディスクに保存されている場合、またはブラウザーが送信した HTTP リクエスト ヘッダーを何らかの方法で書き換えて元のセッション ID をサーバーに送信した場合、ブラウザーが起動したときに元のセッションを見つけることができます。再び開かれます。
ブラウザを閉じてもセッションは削除されず、サーバーにセッションの有効期限の設定が強制されるため、クライアントが最後にセッションを使用してからの時間がこの有効期限を超えた場合、サーバーは、クライアントがアクティビティを停止した場合、ストレージ容量を節約するためにセッションが削除されます。
これから、次の結論を導き出すことができます:
ブラウザを閉じると、ブラウザのメモリ内のセッション Cookie のみが消えますが、サーバーに保存されているセッション オブジェクトは消えませんし、永続的な Cookie がハードディスクに保存されます。
27. 2 つのブラウザ ウィンドウを開くと、アプリケーションにアクセスするために同じセッションが使用されますか? 通常、新しいブラウザ ウィンドウを開いて同じページに入ると、システムは新しいセッションを提供します。 ID は情報共有の目的を無効にするものとします。
このとき、まずセッション ID を永続 Cookie に保存し (セッションの最大有効時間を設定することで)、次にそれを新しいウィンドウで読み取って、前のウィンドウのセッション ID を取得します。セッション Cookie と永続 Cookie を組み合わせることで、クロスウィンドウ セッションの追跡を実現できます。
28. セッションを利用して顧客別の訪問数を表示する方法
顧客の訪問数は整数変数のため、属性型にはint、double、booleanなどの基本型変数は使用できません。これらの基本的なタイプのカプセル化型オブジェクトは、セッション オブジェクトの属性の値として使用されます。ただし、Integer は不変のデータ構造です。構築後に変更することはできません。これは、各リクエストで新しい Integer オブジェクトを作成し、setAttribute を使用して以前に存在していた古い属性の値を置き換える必要があることを意味します。例:
HttpSession session = request.getSession();
SomeImmutableClass value = (SomeImmutableClass)session.getAttribute(“SomeIdentifier”);
if (value= =null){
value = new SomeImmutableClass(…);不変オブジェクト
}else{
value = new SomeImmutableClass(calculatedFrom(value)) // 値を再計算した後に新しいオブジェクトを作成します
}
session.setAttribute("someIdentifier",value) // 新しい作成を使用します。オブジェクトは元の古いオブジェクトを上書きします
29. セッションを使用してユーザー データを蓄積する方法
配列、リスト、マップなどの変更可能なデータ構造、または書き込み可能なフィールドを含むアプリケーション固有のデータ構造を使用します。この方法では、オブジェクトが初めて割り当てられる場合を除き、setAttribute を呼び出す必要はありません。たとえば、
HttpSession session = request.getSession();
SomeMutableClass value = (SomeMutableClass)session.getAttribute("someIdentifier");
if(value == null){
value = new SomeMutableClass(...);
session .setAttribute( "someIdentifier", value);
}else{
value.updateInternalAttribute(...); // オブジェクトがすでに存在する場合、属性をリセットせずに属性を更新します
}
30 個の変更不可能なオブジェクトと変更可能なオブジェクトセッションデータが更新されるときの異なる処理
不変オブジェクトは一度作成すると変更できないため、セッション内の属性の値を変更するたびに、setAttribute("someIdentifier", newValue) を呼び出して元の値を置き換える必要があります属性の値を変更しないと、属性の値は更新されません。通常、変更可能なオブジェクトには独自の属性を変更するためのメソッドが用意されているため、セッション内の属性の値を変更する場合は常に、変更可能なオブジェクトの独自の属性を変更する関連メソッド。このメソッドは問題ありません。これは、setAttribute メソッドを呼び出す必要がないことを意味します。

以上がCookieとセッションの比較の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。