重複の可能性:
PHP セッションまたは Cookie
ユーザーに関する情報をページごとに追跡する新しいプロジェクトを開発しています。セキュリティ、信頼性、およびサーバーの使用状況の観点から、セッションと Cookie のどちらを使用する方がよいでしょうか? ある方法または別の方法を使用することの浮き沈みは何ですか。
たとえば、ユーザーが正常にログインしたかどうかを追跡したり、ユーザーが選択した言語を追跡したりします。
基本的に、Cookie を使用するかセッションを使用するかを決定する方法を知りたいのですが、明らかに、ページへのさまざまなアクセスで発生したデータをさまざまな機会やさまざまな日に追跡したい場合、答えは Cookie を使用することですが、ブラウザを閉じずにページのナビゲーション内を追跡することについて。
ありがとう
Cookieは、HTTP 応答ヘッダーでサーバーからクライアントに送信される小さなテキストです。クライアントはそれをローカルに保存し、リクエストヘッダーのすべてのリクエストでサーバーに返します。これにより、そうでなければステートレスな HTTP プロトコルでいくつかの状態を実装できます。
セッションは、通常は Cookieの上に実装される概念です。サーバーは意味のない一意のセッション トークン (ランダム ID) を Cookie としてクライアントに送信し、クライアントはすべての要求でそれを返します。サーバー側のこの ID は、いくつかのデータに関連付けられています。クライアントが要求でセッション トークンをサーバーに送り返すたびに、サーバーはそのトークンに関連付けられたデータを検索します。
クライアントとサーバー間のセッション ID のやり取りは、セッション ID をすべての URL またはフォーム リクエストに埋め込むことによっても発生します。これは Cookie である必要はありません。ただし、URL にセッション ID を埋め込むことはお勧めできません。URL が異なるユーザー間で共有されている場合に、誤ってセッションが転送される可能性があるためです (以下を参照)。最近のセッションは通常、クライアント側の Cookie を使用して実装されます。
概念的には Cookie とセッションは非常に似ており、どちらも HTTP で状態を実装します。違いは、Cookie は少量のデータしか保存できないことです。このデータはリクエストごとにやり取りされ、ユーザーが編集できます (クライアントに保存される情報であるため)。一方、セッションはすべてのデータをサーバー側に保存するため、サーバーのリソースによってのみ制限されます。セッションが持つ唯一の脆弱性は、ユーザーが別のユーザーのセッション ID を推測または盗むことができる場合、そのユーザーになりすますことができることです。これはセッション ハイジャックと呼ばれます。プレーン Cookie にはセキュリティがまったくないため、重要なことには使用しないでください (ユーザーはコンテンツを表示および編集できるためuserloggedin=yes、Cookie に保存することは最悪の行為です)。