私はコードする必要があるログインシステムがあります。しかし、私が理解していないことは、Remember meがなくてもクライアントマシンにクッキーを保存する必要があるということですか？必要なすべての情報をセッション自体に保存し、それを使ってBasePageをチェックインして、ユーザーが認証されているかどうかを確認すると、セキュリティとセキュリティが向上するのではないでしょうか？私が覚えていない場合でもクライアントマシンにクッキーを保存する必要はありますか？
私の機能を覚えておけば、クッキーが必要になるでしょうか？これにいくつかの光を投げてください。
はい、そうするか、作成するすべてのリンクのクエリ文字列に何かを載せなければなりません。 Webプログラミングは完全にステートレスです。あなたは、クライアント（ブラウザ）に何か毎回サーバに何かを返信させない限り、どのユーザがどのページをリクエストしているのか、あるいはログインしているのか、本当に分かりません。
「www.example.com/page.aspx」というリクエストがあれば、それは私、兄弟、私の猫、他のランダムな人物なのかどうかわかりません。そのページを要求したことを知るためには、セッションクッキーを使用するか、クエリ文字列に値を渡す必要があります。
申し訳ありませんが、私の質問は明確ではありませんでした。私は認証クッキーについて話しています。私が誰であるかを特定するために、私は明らかにセッションIDを保存するセッションクッキーを持っています。私はセッションクッキーについて話していません。 – Jaggu
申し訳ありません。私はあなたの質問の文言を誰か新しいものに言いました.netへ。私がそれを読んだとき、あなたがどこから来ているのかを見ています。そして、あなたは正しいです。セッション間で状態を保存する必要がない場合（つまり、「username」テキストボックスのような情報を事前に入力する必要があるかどうかを知る必要がある場合）、noを指定すると、クライアント上に情報を保持する必要はありません。だから、いいえ、クッキーは必要ありません。 –
querystringを使用してセッション/ ID情報を渡すとセキュリティ上の問題が発生する可能性があります。誤ってURLを共有すると、アンチセッションハイジャック技術を実装しない限り、元のユーザーの代わりに他のユーザーがログオンできます。 – Ramesh
問題は、HTTPプロトコルはステートレスなので、セッション（および要求間の任意のタイプの永続性）は、それが以前のクライアントからのものであることをサーバーに証明するために、そうすれば、あなたは追加の情報を要求と共に送る必要があります。セッションの場合、セッションIDが使用されます。通常は、Cookie経由で実装されます。セッションIDはGET/POSTパラメータとして渡されます（非常に安全でない/推奨されません）。セッションのためにクッキーが必要です。
申し訳ありませんが、私の質問は明確ではありませんでした。私はセッションクッキーを持っています。私が実際に話していることは、FormsAuthentication.Encryptを実行してCookieを応答として保存する必要があるかどうかです。 – Jaggu
それから、あなたは正しかったです。すべてのセッションをサーバー側でのみ保存できます。クッキーは必要ありません。 –
認証と承認はセキュリティに関連しており、状態管理とは異なります。彼らが何のために作られたものを使用してください。また、SessionIdsを再利用できるため、セキュリティ上の問題が発生する可能性があります。 – Ramesh
認証&承認はセッション管理とは異なります。少なくともそれはASP.NETチームが見る方法です。認証/自動化の失敗の場合は、セキュリティ上の理由から、DOS攻撃の可能性があるため、システムはリソースのいずれかを打つべきではありません。セッションを使用して認証および/または自動執行の詳細を保存していて、セッションがDBからのものである場合、無効なユーザーであっても、セキュリティの観点からはうまくいかないDB呼び出しが行われます。したがって、彼らが何のために作られたものを使用します。
申し訳ありませんが、私はあなたの答えを理解していません。私はセッションがDBに格納されていて、無効な呼び出しが行われているとは言いませんでしたか？ – Jaggu
プロバイダを使用してセッションを変更し、将来DBを使用する場合はスケーラビリティを目的としてセッションを変更し、セッション情報を取得するためにDBコールを行う必要があるかどうかを確認できます。したがって、無効なユーザーがあなたのサイトにアクセスし続けた場合、これらのリクエストに対してもDBコールが行われ、サービス拒否が発生します。セキュリティ上の理由から。要するにセキュリティ上の理由からフォーム認証を使用することです。 – Ramesh
今後もセッションを保存する必要はありません。しかし、とにかくありがとう。必要があれば、私はOutProcをスケーラビリティのために使うことができます。 SQL Serverは私の最後の選択でなければなりません。 – Jaggu
認証システムをコーディングする最初のルールは、プラットフォームによって提供される機能（この場合はASP.Netメンバーシップ・プロバイダ）を可能な限りリーンにすることです。 _seems_が動作するように簡単に書くことができます - あなたのすべてのユニットテストを通過することもできますが、6ヵ月後にシステムがハッキングされ、見つからないという微妙な欠陥があります。 1年間 –
@Joel：私はAsp.Netメンバーシップ・プロバイダを使用できません。私のデータベーステーブルは、Microsoftが提供するテーブルとはまったく異なります。だから、私は自分で認証コードを書く必要があります。 – Jaggu
あなたのデータベーステーブルはそれとは関係ありません。それはプロバイダーモデルをまったく使用していない点です。基本モデルを継承して、必要なデータストアと話をします。 –