1. Cookie の起源
ユーザーが Web サイトにアクセスすると、Web サーバーは一部の情報をローカル コンピュータに保存します。ユーザーが Web サイトに再度アクセスすると、サーバーはユーザーが Web サイトにログインしているかどうかを確認します。ログインしている場合は、ローカルに記録された情報を送信します。情報をWebページ上に表示するためにはCookieが存在することになります。
では、サーバーはどのようにしてユーザーを識別するのでしょうか?ご存知のとおり、http プロトコルはステートレス接続です。いわゆるステートレス接続とは、ブラウザがサーバーへのリクエストを開始するたびに、接続を経由せずに、毎回新しい接続を確立することを意味します。接続の場合、サーバー プロセスは接続を維持し、何らかの情報ステータスをメモリに記憶できます。各リクエストが終了すると接続が閉じられ、関連するコンテンツが解放されるため、状態は記憶されず、ステートレス接続になります。 http プロトコルに基づくサーバーの場合、さまざまな接続に対して、サーバーはこれらの接続がすべて同じユーザーからのものであることを識別できないため、Cookie が登場しました。
サーバーに初めてアクセスしたとき、http メッセージには Cookie がありません。このとき、サーバーはブラウザに、応答 (レスポンス) ダウンストリーム HTTP メッセージに Cookie 情報を含めるよう指示します。ブラウザが再度同じサーバーにアクセスすると、ドメインに入ると、上流のHTTPリクエスト(リクエスト)にCookie情報が組み込まれ、HTTPのシミュレーションと状態を実現します。
要約すると、Cookie は実際には小さなテキスト情報です。クライアントはサーバーにリクエストを送信し、サーバーはユーザーのステータスを記録する必要がある場合、応答を使用してクライアントのブラウザに Cookie を発行します。クライアントは Cookie を保存します。ブラウザが Web サイトを再度リクエストすると、ブラウザはリクエストされた URL を Cookie とともにサーバーに送信します。サーバーはこの Cookie をチェックしてユーザーのステータスを識別します。サーバーは必要に応じて Cookie の内容を変更することもできます。
2. Cookie の内容と特性
Cookie の主な内容: 名前、値、ドメイン、パス、有効期限 名前と値属性はプログラム設定で構成され、デフォルト値は null 参照です。Domain 属性のデフォルト値は、この Cookie を送信するページがどのディレクトリにあるかに関係なく、現在の URL のドメイン名部分です。パス属性は、この Cookie がどのディレクトリに発行されるかに関係なく、ルート ディレクトリ、つまり "/" であり、Cookie ページがどのディレクトリに配置されるかは関係ありません。この Cookie の範囲は、プログラムが特定のパスに設定することによってさらに制限できます。Expires 属性は、この Cookie の有効期限の日付と時刻を設定します。
Expires 属性が設定されていない場合、Cookie は自動的に消えるため、セッション Cookie と呼ばれます。セッション Cookie は、ローカル ハード ドライブではなくメモリ内に存在します。有効期限が設定されている場合、ブラウザは Cookie をハード ドライブに保存します。ブラウザを閉じて再度開くと、これらの Cookie は保存されます。設定された有効期限を超えるまでは有効です。ハード ドライブに保存されている Cookie は、ブラウザのさまざまなプロセス間で共有できます。
Cookie の機能:
1. Cookie は暗号化されておらず、自由に改ざんできるため、非常に安全ではありません
2. Cookie は異なるドメイン間で共有できません。以下に示すように、Cookie のサイズは制限されています。
#3. セッションの誕生
# Cookie の安全性が低いという致命的な欠点を補うために、セッション メカニズムが誕生しました。セッションは、クライアントのステータスを記録するためのもう 1 つのメカニズムです。違いは、Cookie がクライアントのブラウザに保存されるのに対し、セッションはサーバーに保存されることです。クライアントのブラウザがサーバーにアクセスすると、サーバーはセッションと呼ばれる何らかの形式でクライアントの情報をサーバーに記録します。
ユーザーがサーバーに接続すると、サーバーはセッションを確立し、サーバーは session_id を使用してどのユーザーがアクセスしているかを識別します。ユーザーがセッションを確立するとき、ユーザー認証が成功したときに一意の Cookie を与えることができます。ユーザーがフォームを送信すると、ブラウザーはユーザーの SessionId を HTTP ヘッダー情報に自動的に追加します。サーバーが処理を完了したとき、このフォームの後、結果は、SessionId に対応するユーザーに返されます。
要約すると、セッションは暗号化されており、Cookie よりも安全です。セッション作成プロセスは次のとおりです: クライアント リクエストのセッションを作成するとき、サーバーはまずリクエストに session_id が含まれているかどうかを確認します。サーバーは session_id を取得した後、サーバーが session_id を保存していない場合は session_id を作成し、そうでない場合はクライアントのセッションを作成し、このセッションに関連付けられた sessionId を生成します。または 簡単に見つけたり偽造したりできない文字列 この sessionId は、保存のためにこの応答でクライアントに返されます。
4. Cookie とセッションの類似点と相違点
Cookie とセッションは同じものだと多くの人が言いますが、違いは、それらがユーザーに表示されるかどうかです。私もこの意見に同意します。セッションの伝達手段として、Cookie はローカル ブラウザに保存されます。操作と保存が簡単です。サーバーのパフォーマンスを効果的に向上させることができます (メモリを占有しない)。ただし、Cookie には次のような欠点があります。安全でないプレーン テキストとして、サイズが制限されています。; セッションはサーバー キャッシュに保存され、暗号化され、session_id サイズに制限はありませんが、サーバーのパフォーマンスに影響します。
Cookie とセッション間の関係について言えば、Cookie の無効化について言及する必要があります。クライアントのブラウザ設定で、ユーザーは Cookie を無効にすることができます。Cookie は session_id のキャリアであるため、Cookie が無効になると、セッションはは使用できません。しかし、依存関係の問題を解決するには 2 つの方法があります。1 つは URL の書き換えです。これは単に URL アドレスに session_id パラメータを追加することを意味します。もう 1 つはフォームの隠しフィールドです。サーバーは自動的にフォームを変更し、隠しフィールドを追加します。以下に示すように、送信時に session_id をサーバーに戻すことができます:
別の接続はセッション共有です。複数の Web サイト (同じ親ドメインと異なるサブドメイン) の場合、解決する必要があるのは、異なる Web サイトからの session_id の共有です。ドメイン名が異なり (aaa.test.com と bbb.test.com)、session_id が独自の Cookie に保存されているため、サーバーは 2 つのサブサイトへのアクセスが異なるセッションからのものであると認識します。解決策は、Cookie のドメイン名を親ドメイン名に変更することで Cookie 共有の目的を達成し、それによって session_id の共有を実現します。欠点は、サブサイト間の Cookie 情報も同時に共有されることです。
5.laravel の関連アプリケーション
session application
config/session 内。 php の設定は次のとおりです:
'driver' => env('SESSION_DRIVER', 'file'), 'lifetime' => 120, 'expire_on_close' => false, 'encrypt' => false, 'files' => storage_path('framework/sessions'), 'connection' => null, 'table' => 'sessions', 'lottery' => [2, 100], 'cookie' => 'laravel_session', 'path' => '/', 'domain' => null, 'secure' => false,
ドライバー設定項目は、セッションの保存方法を設定するために使用されます。デフォルトは file で、ファイルに保存されます。ファイルは、ファイルで設定されたパスにあります。構成アイテム、つまりストレージ/フレームワーク/セッション。さらに、Laravel は他の保存方法もサポートしています。
database: 構成項目テーブルによって設定される、指定されたデータ テーブルにセッション データを保存します。 memcached: Memcached にセッション データを保存します。 redis: 配列にセッション データを保存します。 Redis: セッション データを配列に保存します。この構成はテスト環境でのみ使用されます。ドライバー構成を変更するには、プロジェクト ルート ディレクトリの .env ファイルに移動し、その中の SESSION_DRIVER オプションを変更する必要があります。
ライフタイム設定項目は、セッションの有効期間を設定するために使用されます。デフォルトは 120 分です。 expire_on_close 設定項目は、ブラウザを閉じたときにすぐにセッションを無効にするかどうかを設定するために使用されます。暗号化設定項目は、セッション データを暗号化するかどうかを設定するために使用されます。抽選設定項目は、リサイクルされたセッションの保存場所を設定するために使用されます。 cookie 設定項目は、セッション ID を格納する cookie 名の設定に使用され、デフォルトは laravel_session です。パス設定項目は、セッション ID を保存するための Cookie 保存パスを設定するために使用されます。デフォルトはプロジェクトのルート ディレクトリです。ドメイン構成項目は、セッション ID を保管する Cookie 保管ドメイン名を構成するために使用されます。セキュア構成項目は、セッション ID が HTTPS プロトコルでのみサーバーに送信されるかどうかを構成するために使用されます。
セッション関数を使用する
session(['site.xxx'=>'LaravelAcademy.org']);$site = session('site');dd($site);
リクエスト requestを使用する
すべてのセッション データを次の方法で取得できます:
$sessions = $request->session()->all();
次のようにセッション データにアクセスできます:
$request->session()->put('site', 'https://www.php.cn/');if($request->session()->has('site')){ $site = $request->session()->get('site'); dd($site);}
さらに、次のようにセッション データを取得することもできます (対応するセッションが存在しない場合は、デフォルト値を返します):
$sitename = $request->session()->get('sitename','Laravel');dd($sitename);
さらに、プッシュ メソッドを使用して複数のデータをセッション配列にプッシュすることもできます。
$request->session()->push('site.xxx', 'https://www.php.cn/');$request->session()->push('site.xxx', 'Laravel');if($request->session()->has('site')){ $site = $request->session()->get('site'); dd($site);}使用pull方法,获取数据后删除使用flush方法,一次性删除所有session数据使用forget方法,删除某个session数据
ワンタイム セッション
1 回限りのセッション データが有効な場合は、TestController@sessionx コードを次のように定義できます。
public function sessionx(Request $request){ $request->session()->reflash(); $message = session('message'); echo $message;}
これは、セッション データがどのように更新されるかに関係なく、常に有効になります。さらに、どのセッション データが有効であるかを指定することもできます:
$request->session()->keep(['message']);
また、laravel コードを自分でコンパイルすることもできます:
class Middleware implements HttpKernelInterface{ ... public function handle(Request $request, $type = HttpKernelInterface::MASTER_REQUEST, $catch = true) { $this->checkRequestForArraySessions($request); if ($this->sessionConfigured()) { $session = $this->startSession($request); // 启动session $request->setSession($session); } $response = $this->app->handle($request, $type, $catch); // 调用controller的method if ($this->sessionConfigured()) { $this->closeSession($session); //关闭session $this->addCookieToResponse($response, $session); } return $response; } ... protected function closeSession(SessionInterface $session) { $session->save(); // 保存session $this->collectGarbage($session); } }
Cookie application
#Cookie の追加
たとえば、コントローラーに Cookie 値「Hello, Laravel」を設定し、有効期間を 10 分に設定する必要があります。 Cookie は自動的に応答に追加されるため、ここでは Cookie キュー メソッド Cookie::queue() を使用することをお勧めします。 Cookie の使用は、レスポンスとリクエストを切り離すことができません。 Cookie の値を取得するには 2 つのレベルがあり、1 つはサーバー、もう 1 つはクライアントです。サーバーに Cookie の値を取得させたい場合は、リクエストから取得する必要があります:<?php namespace App\Http\Controllers; use Cookie; use App\Http\Controllers\Controller; class DashboardController extends Controller{ public function index() { Cookie::queue('younger', 'Hello, dayang', 30); return view('welcome'); } }
public function index(Request $request) { $cookie = $request->cookie('younger'); dump($cookie); }
public function index(Request $request){
$cookies = $request->cookie();
dump($cookies);
}
\Cookie::queue(\Cookie::forget('younger'));或 \setcookie('younger', '', -1, '/');
laravel フレームワークの技術記事については、
laravel チュートリアルをご覧ください。
以上がLaravelフレームワークにおけるセッションとCookieの仕組みと関連アプリケーションの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。