現在、Web サイトを更新していますが、ログイン/セキュリティ モードを更新するのであれば、今が良い時期だと考えています。
私は ASP.NET に含まれているメンバーシップ モデルに目を通しましたが、他の .NET 開発者が慣れ親しんでいること以外に利点があるとは確信していません。
それについてはかなり多くのドキュメントがあるようですが、なぜ努力する価値があるのかについての議論はほとんどありません.
誰かがこれに光を当てることができますか?
現在、Web サイトを更新していますが、ログイン/セキュリティ モードを更新するのであれば、今が良い時期だと考えています。
私は ASP.NET に含まれているメンバーシップ モデルに目を通しましたが、他の .NET 開発者が慣れ親しんでいること以外に利点があるとは確信していません。
それについてはかなり多くのドキュメントがあるようですが、なぜ努力する価値があるのかについての議論はほとんどありません.
誰かがこれに光を当てることができますか?
大規模なサイトでメンバーシップを使用するメリットはほとんどないと思います。これは、ASP.Net 認証の「the」ソリューションとして販売されています。しかし、実際には、Microsoft は古い Membership Server 製品を、誰もが突然必要とするものとして位置付けようとしているようです。
私は約 10 年前に Msft でメンバーシップ サーバーに取り組んでいました。shop.microsoft.com の主任開発者でもありましたが、そのサイトでは内部サーバー製品を使用していませんでした。コマース サーバーでもメンバーシップ サーバーでもありません。彼らが今それをどのように行っているかはわかりませんが、その時点での一般的なコンセンサスは、これらのタイプのパッケージは一般的に私たちがやろうとしていることの邪魔になるということだったと思います.
これは、小規模なサイトや、リソースが限られている場合に役立ちます。たとえば、時間やリソースをあまり投資したくない部門または小規模企業のイントラネットで数百人のユーザーがいる場合です。見れば見るほど、大規模なカスタム Web サイトにはまったく不適切であることがわかります。
私が本当に理解していないのは、ほとんどすべての ASP.Net ブックが、これを 1 つの方法ではなく、それを行う唯一の方法として推進しているように見えることです。
ASP.NET メンバーシップ プロバイダーのすべてのストアド プロシージャを読んだ後、独自の手順を作成しました。難しいことではなく、最終的にはより多くのことをコントロールできます。
XML 構成、ロールの弱い型指定の文字列、デフォルトでは安全ではない、「アカウントは必要ありません」と言うページ クラスのクリーンなマーカー インターフェースの代わりにランダムな web.config ファイルがディレクトリに散らばっているのが好きなら、単一のデータベースに対して複数のデータベース ヒットログイン、現在の ObjectContext/DataContext からロードされていないユーザー オブジェクト、およびその場でプロバイダーを変更する機能 (ウーフー、誰がそれを使用しますか?!) は、組み込みのものを使用します。
そうでない場合は、独自に作成しますが、作成する場合は、パスワードの暗号化/ソルトハッシュを保存し、適切な暗号化 Cookie を実行してください。
[コメントのフィードバックを反映して更新]
この特定のサイトで作業するのがあなただけでない限り、.NET 開発者にとって使い慣れているという事実が、組み込みのメンバーシップ ルートを使用する十分な理由だと思います。ASP.NET の経験を持つ他の開発者は、プロジェクトに飛び込んで、サイトの認証/承認モデルにすぐに慣れることができます。
サイトで組み込みのメンバーシップおよびロール プロバイダー モデルを使用しており、非常にうまく機能しています...データ用に別のバッキング ストアを使用しているため (Microsoft Dynamics CRM を使用)、独自のプロバイダー クラスを作成する必要がありましたが、これらのクラスは非常に単純で、十分に文書化されています。この作業を前もって行うことで、コードで Membership クラスと Roles クラスを使用できるようになり、ページでさまざまなログイン関連のサーバー コントロールを使用できるようになります。
あなたが検討している別の選択肢はありますか?
.Net に付属する MembershipProvider について私が本当に嫌いな唯一の点は、ユーザー ID が自動インクリメント ID ではなく GUID であることです。GUID を使用すると利点があることはわかっていますが、既存のシステムやモジュールに統合するのは面倒です。
自分でロールバックする必要がないように、単純にそこにあります。
ASP.NET メンバーシップ、ロール、およびプロファイルの魅力的な機能は、プロバイダー モデルを使用していることです。現状に満足できない場合は、基本クラスから独自のものを作成することは難しくありません。codeplex.com を見ると、人々が作成したカスタム プロバイダーがおそらく 12 個以上あるはずです。数年前に SQLite データベース用に書きました。
その価値は、すぐに使用できる構築済みの役割ベースのセキュリティ フレームワークであることです。独自のフレームワークを既に構築しており、移行が簡単でない場合は、その価値がない可能性があります。ただし、移行の利点の 1 つは、多くのアプリケーション コードを削除して、フレームワーク コードに置き換えることができることです。
メンバーシップ ルートはうまく機能しますが、致命的な欠陥が 1 つあります。私は Microsoft を責めません。
Internet Explorer は、認証キャッシュを適切に破棄できる唯一のブラウザーです。
Firefox ブラウザーを閉じて開き、最後のセッションを復元して、ログインせずに「安全な」Web サイトにすぐに戻ることができます。Chrome にも同様の問題があり、Mac にも同じことが起こります。
IE には、これを正しく処理する JavaScript 呼び出しがあります: document.execCommand("ClearAuthenticationCache", "false");
他のブラウザでは動作しません。これを使用する場合は、ユーザーに IE の使用を強制する必要があります。
Community Server や DotNetNuke などの既に作成されているポータル ソフトウェアにサイトを移行したい場合は、メンバーシップ プロバイダーを使用すると簡単に移行できます。既存のデータベースを使用することもでき、新しいデータベースを実装する必要はありません。