Pythonを使用して、Webアプリケーション開発の学習を始めたばかりです。「クッキー」と「セッション」という用語に出くわしました。Cookieは、ブラウザのキーと値のペアにいくつかの情報を格納するという点で理解しています。しかし、セッションに関して少し混乱があります。セッションでも、ユーザーのブラウザーのCookieにデータを保存します。

たとえば-とを使用username='rasmus'してログインしますpassword='default'。このような場合、データはサーバーに送信され、認証された場合はチェックしてログインすることになっています。ただし、プロセス全体の間、サーバーはブラウザーのCookieに保存されるセッションIDも生成します。これで、サーバーはこのセッションIDをファイルシステムまたはデータストアにも保存します。

しかし、セッションIDだけに基づいて、サイトを次にトラバースするときに、ユーザー名をどのように知ることができますか？キーはセッションIDでありusername、emailなどの詳細は値であるdictとしてサーバーにデータを保存しますか？

私はここでかなり混乱しています。助けが必要。

HTTPはステートレスであるため、リクエストを他のリクエストに関連付けるには、HTTPリクエスト間でユーザーデータを保存する方法が必要です。

CookieまたはURLパラメータ（例：http://example.com/myPage?asd=lol&boo=noなど）は、2つ以上のリクエスト間でデータを転送するための適切な方法です。ただし、クライアント側でそのデータを読み取り/編集可能にしたくない場合は、これらは適切ではありません。

解決策は、そのデータサーバー側を保存し、それに「ID」を与え、クライアントにそのIDのみを通知（およびすべてのhttpリクエストで返す）することです。これで、セッションが実装されました。または、クライアントを便利なリモートストレージとして使用できますが、データを暗号化して秘密をサーバー側に保持します。

もちろん、他にも考慮すべき側面があります。たとえば、他の人のセッションを乗っ取ってほしくない、セッションを永久に持続させるのではなく期限切れにするなどです。

特定の例では、ユーザーID（ユーザーデータベース内のユーザー名または別の一意のIDの可能性があります）は、正常に識別された後、サーバー側のセッションデータに格納されます。次に、クライアントから取得するすべてのHTTPリクエストに対して、セッションID（クライアントから指定）は、認証されたユーザーIDを含む（サーバーによって保存された）正しいセッションデータを示します。これにより、コードはどのユーザーにアクセスするかを認識します。と話している。

類推による簡単な説明

あなたが銀行にいて、口座からお金を引き出そうとしていると想像してください。しかし、それは暗いです。土手は真っ暗です。光がなく、顔の前に手を見ることができません。あなたは別の20人に囲まれています。それらはすべて同じように見えます。そして、誰もが同じ声を持っています。そして、誰もが潜在的な悪者です。つまり、HTTPはステートレスです。

この銀行は面白いタイプの銀行です-議論のために、ここでは物事がどのように機能するかを示します：

1. あなたは並んで（またはオンラインで）待機し、窓口係と話します。お金を引き出すように要求し、次に
2. ソファーでちょっと待って、20分後に
3. あなたは行って実際にテラーからお金を集めなければなりません。

しかし、窓口係は他の誰からも離れてあなたにどのように伝えますか？

明かりがすべて消えているので、窓口係はあなたを見ることができず、すぐに認識することもできません。あなたの窓口があなたの$ 10,000の引き出しを他の誰か-間違った人に与えたら？！あなたが要求したお金（または資源）を手に入れることができるように、出納係があなたを引き出しをした人としてあなたが認識することが絶対に重要です。

解決：

あなたが最初に窓口係に現れたとき、彼または彼女は秘密裏にあなたに何かを話します：

「あなたが私と話しているときはいつでも、あなたは最初に自分をGNASHEU329として識別する必要があります-そうすれば私はそれがあなただとわかります。」

誰も秘密のパスコードを知りません。

現金を引き出す方法の例：

それで、20分間冷やすことに決め、その後、窓口に行って「引き出しを集めたい」と言います。

窓口係は私に尋ねます：「あなたは誰ですか？！」

「ジョージバンクスさん、私です！」

"証明する！"

そして、私は彼らに私のパスコードを教えます：GNASHEU329

「確かにバンクス氏！」

これが基本的にセッションの仕組みです。それは何百万もの人々の海でユニークに識別されることを可能にします。窓口係と取引するたびに、自分を特定する必要があります。

ご不明な点がある場合や不明な点がある場合は、コメントを投稿してください。わかりやすく説明します。

写真による説明：

「セッション」とは、ユーザーがWebサイトを閲覧する時間を指す用語です。これは、サイト内のページに最初に到達してからサイトの使用を停止するまでの時間を表すためのものです。実際には、ユーザーがいつサイトを使い終わったかを知ることは不可能です。ほとんどのサーバーでは、同じユーザーが別のページを要求しない限り、セッションが自動的に終了するタイムアウトがあります。

ユーザーが初めて接続したときに、ある種のセッションIDが作成されます（その方法は、Webサーバーソフトウェアと、サイトで使用している認証/ログインのタイプによって異なります）。Cookieと同様に、セキュリティ上の問題のため、通常はURLで送信されません。代わりに、まとめてセッションとも呼ばれる他の多くのアイテムと一緒に保存されます。セッション変数はCookieのようなもので、ページのリクエストとともに送信され、サーバーからページとともに返される名前と値のペアですが、それらの名前はWeb標準で定義されています。

一部のセッション変数は、HTTPヘッダーとして渡されます。それらはすべてのページ閲覧の舞台裏で前後に渡されるので、ブラウザに表示されず、プライベートである可能性があることをすべての人に伝えません。その中には、USER_AGENT、またはページを要求しているブラウザーのタイプ、REFERRER、または要求されているページにリンクしているページなどがあります。一部のWebサーバーソフトウェアは、独自のヘッダーを追加したり、サーバーソフトウェア固有の追加セッションデータを転送したりします。しかし、標準的なものはかなり文書化されています。

お役に立てば幸いです。

HTTPはステートレスな接続プロトコルです。つまり、サーバーは異なるユーザーの異なる接続を区別できません。

したがって、Cookieが発生し、クライアントがサーバーに初めて接続すると、サーバーは新しいセッションIDを生成します。これは、後でCookie値としてクライアントに送信されます。そして、これ以降、このセッションIDはそのクライアント接続を識別します。これは、各HTTPリクエスト内でCookie内に適切なセッションIDが表示されるためです。

これで、各セッションIDに対して、サーバーはいくつかのデータ構造を保持し、ユーザー固有のデータを格納できるようになります。このデータ構造は、セッションを抽象的に呼び出すことができます。

HTTPは、短期記憶喪失があり、その人が見えなくなるとすぐにすべての人を忘れる人（A）と考えてください。

さて、別の人を思い出すために、Aはその人の写真を撮って保管します。各人の写真にはID番号があります。その人が再び見えてくると、その人は自分のID番号をAに伝え、AはID番号で自分の写真を見つけます。そして出来上がり!!、Aはその人が誰であるかを知っています。

HTTPについても同様です。短期記憶喪失に苦しんでいます。セッションを使用して、Webサイトの使用中に行ったすべてのことを記録し、次に戻ってきたときに、Cookieを使用してユーザーを識別します（Cookieはトークンのようなものです）。写真はここのセッション、IDはここのCookieです。