セッションとは何ですか？彼らはどのように機能しますか？
私は、Pythonを使用してWebアプリケーション開発の学習を開始し始めたところです。 「Cookie」と「セッション」という用語に出くわします。クッキーは、ブラウザのキーと値のペアに情報を保存するという点で理解しています。しかし、セッションについては少し混乱しています。セッションでも、ユーザーのブラウザのCookieにデータを保存します。
たとえば、username='rasmus'とpassword='default'を使用してログインします。このような場合、データはサーバーに送信され、認証された場合にチェックしてログインすることになっています。ただし、プロセス全体の間に、サーバーはセッションIDを生成します。セッションIDは、ブラウザーのCookieに保存されます。サーバーは、このセッションIDをファイルシステムまたはデータストアにも保存します。
しかし、セッションIDだけに基づいて、その後のサイトのトラバース中にどのようにしてユーザー名を知ることができますか？キーがセッションIDであり、username、emailなどの詳細が値になるディクショナリとしてサーバーにデータを保存しますか？
ここではかなり混乱しています。助けが必要。
HTTPはステートレスであるため、リクエストを他のリクエストに関連付けるには、HTTPリクエスト間でユーザーデータを保存する方法が必要です。
CookieまたはURLパラメーター（たとえば http://example.com/myPage?asd=lol&boo=no のような）は、2つ以上のリクエスト間でデータを転送するのに適した方法です。ただし、そのデータをクライアント側で読み取り/編集できるようにしたくない場合には、これらは適切ではありません。
解決策は、そのデータサーバー側を保存し、「id」を与え、クライアントにそのidのみを通知する（そして、http要求ごとに返す）ことです。セッションが実装されました。または、クライアントを便利なリモートストレージとして使用できますが、データを暗号化し、秘密のサーバー側を保持します。
もちろん、他のセッションをハイジャックしたくない、セッションを永久に有効期限切れにするのではなく、期限切れにするなど、考慮すべき他の側面があります。
特定の例では、ユーザーID（ユーザーデータベース内のユーザー名または別の一意のIDの場合があります）は、識別に成功した後、サーバー側のセッションデータに格納されます。次に、クライアントから取得するすべてのHTTPリクエストに対して、セッションID（クライアントが指定）が、認証されたユーザーIDを含む正しいセッションデータ（サーバーが保存）を示します。これにより、コードはどのユーザーと話している。
類推による簡単な説明
あなたが銀行にいて、あなたの口座からいくらかのお金を引き出しようとしていると想像してください。しかし、それは暗いです。銀行は真っ暗です。光がなく、顔の前に手を見ることができません。あなたはさらに20人に囲まれています。それらはすべて同じに見えます。そして、誰もが同じ声を持っています。そして、誰もが潜在的な悪者です。つまり、HTTPはステートレスです。
この銀行はおもしろいタイプの銀行です-議論のために、物事の仕組みを以下に示します。
- あなたは並んで（またはオンラインで）待ってから窓口係に話をします：あなたはお金を引き出す要求をし、それから
- ソファで少し待たなければならず、20分後に
- 実際に出納係からお金を集める必要があります。
しかし、窓口係は他のすべての人からどのようにあなたに伝えますか？
明かりはすべて消えているので、窓口係はあなたを見たり、すぐに認識したりできません。窓口係が他の誰かに間違った人に10,000ドルの引き出しを与えるとどうなりますか？！出納係があなたを引き出した人として認識できるようにすることは絶対に不可欠です。そうすれば、あなたが要求したお金（または資源）を手に入れることができます。
解決策：
あなたが出納係に最初に現れるとき、彼または彼女はあなたに秘密に何かを話します：
「あなたが私と話しているときはいつでも、最初に自分自身をGNASHEU329として識別する必要があります-そのように私はそれがあなただということを知っているべきです」とテラーは言います。
誰も秘密のパスコードを知らない。
現金の引き出し方法の例：
だから私は20分間冷やしてから、出納係に行き、「引き出しを回収したい」と言います。
テラーは私に尋ねます：「あなたは誰ですか??！」
「ジョージ・バンクスさん、私です！」
"証明する！"
そして、私は彼らに私のパスコードを伝えます：GNASHEU329
「確かにミスター・バンクス！」
それが基本的にセッションの仕組みです。数百万人の海で一意に特定することができます。窓口係と取引するたびに、自分自身を識別する必要があります。
ご不明な点がある場合や不明な点がある場合は、コメントを投稿してください。コメントを削除しようとします。
写真による説明：
「セッション」とは、ユーザーがWebサイトを閲覧する時間を指すために使用される用語です。サイトのページに最初に到着してから、サイトの使用を停止するまでの時間を表すことを意図しています。実際には、ユーザーがいつサイトを使用したかを知ることは不可能です。ほとんどのサーバーでは、同じユーザーが別のページを要求しない限り、セッションが自動的に終了するタイムアウトがあります。
ユーザーが初めて接続したときに、ある種のセッションIDが作成されます（その方法は、Webサーバーソフトウェアと、サイトで使用している認証/ログインの種類によって異なります）。クッキーのように、これは通常、セキュリティの問題であるため、URLで送信されなくなります。代わりに、集合的にセッションとも呼ばれる他のデータの束とともに保存されます。セッション変数はCookieのようなものです。ページのリクエストとともに送信され、サーバーからページとともに返される名前と値のペアですが、名前はWeb標準で定義されています。
一部のセッション変数は HTTPヘッダー として渡されます。それらはすべてのページ閲覧の舞台裏でやり取りされるため、ブラウザに表示されず、プライベートである可能性があることを皆に伝えません。それらの中には、USER_AGENT、またはページを要求するブラウザーのタイプ、REFERRER、または要求されているページにリンクしたページなどがあります。一部のWebサーバーソフトウェアは、独自のヘッダーを追加するか、サーバーソフトウェアに固有の追加のセッションデータを転送します。しかし、標準的なものはかなりよく文書化されています。
お役に立てば幸いです。
HTTPはステートレスな接続プロトコルです。つまり、サーバーは異なるユーザーの異なる接続を区別できません。
したがって、Cookieが発生します。クライアントがサーバーに初めて接続すると、サーバーは新しいセッションIDを生成します。このセッションIDは、後でCookie値としてクライアントに送信されます。これ以降、このセッションIDはそのクライアント接続を識別します。これは、各HTTPリクエスト内でCookie内の適切なセッションIDが表示されるためです。
現在、各セッションIDについて、サーバーは何らかのデータ構造を保持しているため、ユーザー固有のデータを保存できます。このデータ構造は、セッションを抽象的に呼び出すことができます。
HTTPは、短期記憶喪失があり、その人が見えなくなるとすぐにすべての人を忘れる人（A）と考えてください。
さて、さまざまな人物を思い出すために、Aはその人物の写真を撮り、それを保管します。各人物の写真にはID番号があります。その人が再び目の前に来ると、その人はID番号をAに伝え、Aは自分の写真をID番号で見つけます。そして出来上がり!!、Aはその人が誰であるかを知っています。
HTTPも同じです。短期記憶喪失に苦しんでいます。セッションを使用して、Webサイトの使用中に行ったすべてを記録します。その後、再度アクセスすると、Cookieを使用して識別します（Cookieはトークンのようなものです）。画像はここのセッションであり、IDはここのCookieです。