PHP は Cookie とセッションのメカニズムを正しく理解します

Cookie とセッションのメカニズムを正しく理解する

php における cookie とセッションのメカニズムの違いと関係

具体的には、Cookieの仕組みはクライアント側で状態を保持するソリューションを採用しています。これはユーザー側のセッション状態の保存メカニズムであり、ユーザーはクライアント側で Cookie サポートをオンにする必要があります。 Cookie の役割は、HTTP プロトコルのステートレスな欠陥を解決するための取り組みです。

セッション メカニズムは、クライアントとサーバーの間で状態を維持するソリューションを使用します。同時に、サーバー側で状態を維持するソリューションではクライアント側でも ID を保存する必要があるため、セッション メカニズムでは ID を保存するという目的を達成するために Cookie メカニズムを使用する必要があることもわかりました。セッションは、グローバル変数を管理する便利な方法を提供します

セッションはユーザーごとに保存されます。セッション ID は、アクセス時にユーザーのブラウザを通じてサーバーに返されます。クライアントは Cookie を無効にします。この値は、get によってサーバーに返されるように設定することもできます。

セキュリティの観点: セッションを使用するサイトにアクセスしてマシンに Cookie を作成する場合、サーバー側の SESSION メカニズムは、顧客が保存した情報を恣意的に読み取らないため、より安全であることが推奨されます。

オーソドックスな Cookie の配布は、HTTP プロトコルを拡張することによって実現されます。サーバーは、HTTP 応答ヘッダーに特別な命令行を追加し、その命令に従って対応する Cookie を生成するようブラウザーに指示します。

Web サーバーの観点から見ると、すべての HTTP リクエストは以前のリクエストから独立しています。つまり、各 HTTP 応答は、対応するリクエスト

に含まれる情報に完全に依存しています。

状態管理メカニズムは HTTP のいくつかの制限を克服し、ネットワーク クライアントとサーバーがリクエスト間の関係を維持できるようにします。この関係が維持される期間をセッションと呼びます。

Cookie は、サーバーによってローカル マシンに保存される小さなテキストであり、リクエストごとに同じサーバーに送信されます。 IETFRFC2965HTTPStateManagementMechanism はユニバーサル Cookie 仕様です。 Web サーバーは、HTTP ヘッダーを使用してクライアントに Cookie を送信します。クライアント端末では、ブラウザーがこれらの Cookie を解析し、ローカル ファイルとして保存します。同じサーバーへのリクエストはすべて、これらの Cookie に自動的にバインドされます。

----------------------------------------------- -------------------------------------------------- -------------------------------------------------- -----------------

セッションの仕組みを理解する

セッション メカニズムはサーバー側のメカニズムであり、サーバーは情報を保存するためにハッシュ テーブルに似た構造を使用します (またはハッシュ テーブルを使用する場合もあります)。

プログラムがクライアントのリクエストに対してセッションを作成する必要がある場合、サーバーはまずクライアントのリクエストに sessionid と呼ばれるセッション識別子が既に含まれているかどうかを確認します。セッション ID が既に含まれている場合は、このクライアントが以前に使用されたことを意味します。クライアントがセッションを作成している場合、サーバーはセッションを取得し、セッション ID に従って使用します (取得できない場合は、新しいセッションを作成する可能性があります)。クライアントのリクエストにセッション ID が含まれていない場合、セッションは作成されます。クライアント用に作成され、セッションに関連するセッションが生成されます。セッション ID の値は、繰り返されず、偽造されるパターンも簡単に見つけられない文字列である必要があります。このセッション ID はクライアントに返され、保存されます。この反応。

このセッション ID を保存する方法では Cookie を使用できるため、対話プロセス中に、ブラウザーはルールに従ってこの ID をサーバーに自動的に表示できます。通常、この Cookie の名前は SEEESIONID に似ています。たとえば、WebLogic によって生成された Cookie、JSESSIONID=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764 の場合、その名前は JSESSIONID です。

Cookie は人為的に無効にできるため、Cookie が無効になっている場合でもセッション ID をサーバーに戻す他のメカニズムが必要です。頻繁に使用されるテクノロジは URL 書き換えと呼ばれるもので、セッション ID を URL パスの末尾に直接追加します。1 つは http:// の形式で URL パスに追加情報として追加する方法です。 .... ./x​​xx;jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764

もう 1 つは、http://..../xxx?jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764

の形式で、URL の末尾に追加されるクエリ文字列としてのものです。

ユーザーにとってこれら 2 つの方法に違いはありませんが、サーバーが解析中にこれらを処理する方法が異なります。最初の方法を使用すると、セッション ID 情報を通常のプログラム パラメーターと区別するのにも役立ちます。

インタラクション全体を通じて状態を維持するには、クライアントが要求する各パスの最後にこのセッション ID を含める必要があります。

もう 1 つの手法は、フォーム非表示フィールドと呼ばれます。つまり、サーバーは自動的にフォームを変更し、隠しフィールドを追加して、フォームの送信時にセッション ID をサーバーに返すことができるようにします。たとえば、以下のフォーム

はクライアントに渡される前に

に書き換えられます

このテクノロジーは現在ではほとんど使用されていません。著者が接触した非常に古い iPlanet6 (SunONE アプリケーション サーバーの前身) はこのテクノロジーを使用しています。

実際、この手法はアクションに URL 書き換えを適用するだけで簡単に置き換えることができます。

セッションの仕組みについて話していると、「ブラウザを閉じればセッションは消えてしまう」という誤解をよく聞きます。実際、会員カードの例を想像していただければわかると思いますが、お客様が積極的にお店にカードの解約を申し出ない限り、お店は簡単にお客様の情報を削除することはありません。セッションについても同様です。プログラムがサーバーにセッションを削除するように通知しない限り、サーバーは通常、ユーザーがログオフするときにセッションを削除する指示を送信します。ただし、ブラウザは閉じる前にサーバーに閉じようとしていることを積極的に通知することはないため、サーバーはブラウザが閉じられたことを知る機会がありません。これは、ほとんどのセッション メカニズムがセッション ID を保存するためにセッション Cookie を使用するためです。ブラウザを閉じるとセッション ID が消え、サーバーに再度接続すると元のセッションが見つかりません。サーバーによって設定された Cookie がハードディスクに保存されている場合、またはブラウザーによって送信された HTTP リクエスト ヘッダーを書き換えて元のセッション ID をサーバーに送信する何らかのメソッドが使用されている場合、ブラウザを開いたときに元のセッションを見つけることができます。また。

ブラウザを閉じてもセッションは削除されないため、サーバーはセッションの有効期限を設定する必要があり、クライアントが最後にセッションを使用してからの時間がこの有効期限を超えると、サーバーは次のようにみなします。クライアントが停止しました。アクティビティがアクティブな場合、ストレージ領域を節約するためにセッションが削除されます。

----------------------------------------------- -------------------------------------------------- -------------------------------------------------- - ------------------

JSESSIONID は、Cookie と SESSION の違いと関係について説明します

投票などの場合、公平性の原則から、各人が 1 票しか投票できないことがよくあります。このような状況では、通常、これを実現するために COOKIE を使用します。次のコードのように:

   cookie[]cookies=request.getCookies();  
　　if(cookies.lenght==0||cookies==null)  
　　doStuffForNewbie();  
　　//没有访问过  
　　}  
　　else  
　　{  
　　doStuffForReturnVisitor();//已经访问过了  
　　}  

これは非常にシンプルで分かりやすい原理ですが、COOKIEが存在する場合はCOOKIEを書き込むコードが実行されたことになります。コントロールパネル-インターネットオプション-設定-ファイルの表示からいつでもdoStuffForReturnVisitor()を実行できますが、それでも生成されたCookieファイルが表示されないのは明らかにコードに問題はありませんが、Cookieがあるので試してみましょう。それらを表示します。

　　cookie[]cookies=request.getCookies();  
 　　if(cookies.lenght==0||cookies==null)  
 　　　　out.println("Hasnotvisitedthiswebsite");  
 　　}  
　　else 
　　{  
　　　　for(inti=0;i　　{  
　　　　　　out.println("cookiename:"+cookies[i].getName()+"cookievalue:"+  
　　　　　　cookie[i].getValue());  
　　　　}  
　　}  

実行結果:

Cookiename:JSESSIONIDcookievalue:KWJHUG6JJM65HS2K6なぜ Cookie があるのですか? ご存知のとおり、http は顧客が Web ページを読むたびに新しいセッションを開き、サーバーは顧客のコンテキスト情報を自動的に維持しません。では、オンライン ストアにショッピング カートを実装するにはどうすればよいでしょうか? Session は、ユーザーごとに変数の値が保存され、SessionID によって異なる顧客が区別されます。 Cookie はデフォルトで使用され、永続的な Cookie を区別するためにセッション Cookie と呼ばれます。セッション Cookie はストレージです。これはブラウザのメモリに保存され、ハードディスクには書き込まれません。これは先ほど確認した JSESSIONID です。通常は JSESSIONID を確認できませんが、ブラウザで Cookie を無効にすると、Web サーバーは Sessionid を渡します。 URL を書き換えると、アドレス バーに sessionid=KWJHUG6JJM65HS2K6 などの文字列が表示されます。

原理を理解すると、永続的な Cookie とセッション Cookie の違いをインターネット上で簡単に区別できるようになります。セッション Cookie は特定のセッションに関するものです。セッションが終了すると、セッション Cookie は消滅します。永続的な Cookie はクライアントのハード ドライブ上に存在する単なるテキスト (通常は暗号化された) であり、Cookie に対する Cookie スプーフィングやクロスサイト スクリプティング攻撃の対象となる可能性があります。当然、セッション Cookie ほど安全ではありません。

通常、セッション Cookie は複数のウィンドウで使用できません。新しいブラウザ ウィンドウを開いて同じページに入ると、システムは新しいセッション ID を提供します。この方法では、当社の情報共有の目的は達成されません。今回は、まずセッション ID を永続 Cookie に保存し、次に新しいウィンドウでそれを読み取って、前のウィンドウのセッション ID を取得します。このようにして、セッション Cookie と永続 Cookie を組み合わせることで、これを実現できます。クロスウィンドウ セッション トラッキング (セッション トラッキング)。

一部の Web 開発書籍では、セッションと Cookie は単純に 2 つの並行した HTTP 情報送信メソッドとしてみなされます。セッション Cookie はサーバー側にあり、永続的な Cookie はクライアント側にあります。しかし、セッションは Cookie に基づいています。 2 つの関係と違いを理解すれば、Web サービスを開発するために適切なテクノロジーを選択することは難しくありません。