コーディングする必要があるログインシステムがあります。しかし、私が理解していないのは、Remember me? がない場合でもクライアント マシンに Cookie を保存する必要があるかということです。必要なすべての情報をセッション自体に保存し、それを使用して BasePage をチェックインして、ユーザーが認証されているかどうかを確認すれば、より安全で「安全」ではないでしょうか?
私を記憶する機能を構築する場合、Cookie が必要でしたよね? これに光を当ててください。
コーディングする必要があるログインシステムがあります。しかし、私が理解していないのは、Remember me? がない場合でもクライアント マシンに Cookie を保存する必要があるかということです。必要なすべての情報をセッション自体に保存し、それを使用して BasePage をチェックインして、ユーザーが認証されているかどうかを確認すれば、より安全で「安全」ではないでしょうか?
私を記憶する機能を構築する場合、Cookie が必要でしたよね? これに光を当ててください。
そうしないと、作成するすべてのリンクのクエリ文字列で何かを実行する必要があります。Web のプログラミングは完全にステートレスです。クライアント(ブラウザ)に毎回サーバーに送り返す何かを与えない限り、どのユーザーがどのページを要求しているか、またはログインしているかは本当にわかりません。
リクエストに対して「www.example.com/page.aspx」しか得られない場合、それが私なのか、私の兄弟なのか、私の猫なのか、他のランダムな人なのかわかりません。そのページを要求したのが ME であること (したがって、そのページを使用する権限があること) を知るには、セッション Cookie を使用するか、クエリ文字列に値を渡す必要があります。
問題は、HTTP プロトコルがステートレスであるため、セッション (および要求間のあらゆる種類の永続性) では、連続する要求が、前のクライアントからのものであることをサーバーに証明する必要があることです。そうすれば、リクエストとともに追加情報を送信する必要があります。セッションの場合、セッション ID が使用され、通常は Cookie を介して実装されるか、セッション ID を GET/POST パラメーターとして渡します (非常に安全ではなく、推奨されません)。したがって、セッションには Cookie が必要です。
認証と承認は、セッション管理とは異なります。少なくとも、ASP.NET チームはそのように考えています。認証/承認が失敗した場合、DOS 攻撃が発生する可能性があるため、セキュリティ上の理由から、システムはリソースにヒットしないようにする必要があります。セッションを使用して認証および/または認可の詳細を保存し、セッションがDBからのものである場合、無効なユーザーであってもDB呼び出しが行われ、セキュリティの観点からは良くありません. したがって、物事はその目的のために使用されます。