.Netカスタムメンバーシッププロバイダーを使用/作成することの短所は何ですか？

最近、私はSOに次の質問を投稿しました：https : //stackoverflow.com/questions/7197337/using-asp-net-membership-provider-with-an-existing-user-database

お気づきかもしれませんが、「カスタムメンバーシッププロバイダー」を作成/実装することが道であるように見えたという自分自身の質問に答えることになりました。

文字通り、数分後、私はこの質問に出くわしました：https : //stackoverflow.com/questions/7222306/simple-login-attempt-counter-using-mvc-3-and-ajax/7222407#7222407

私は、.Netメンバーシッププロバイダーが「多くのレベルでひどい」と答え、コメントを返そうとします。認めますが、これはメンバーシッププロバイダーを使用するのはこれが初めてですが、確かに滑らかに見えました。

「ひどい」主張を裏付けるものは見たことがありませんので、「ひどい」何かを実装する前に、コミュニティからフィードバックをもらいたいと思っていました。

だから、ここで「ひどい」が最高の言葉かどうかはわかりません。ただし、それには制限があり、ニーズがメンバーシッププロバイダーの設計方法に合わない場合、すぐに多くのグルーコードが作成されます。すぐにメンバーシッププロバイダーを使用できる場合は、ぜひ行ってください。あなたがカスタムのものを書き始めるとすぐに、とにかくメンバーシップのものを使用して質問します。

私の経験では、メンバーシッププロバイダーはあなたを買います...

• MVCアプリに既に組み込まれているサインアップ
• アカウント編集
• パスワードを忘れた場合は簡単に接続できます
• ユーザーメソッドの検証

私は私が行方不明になっている何かがあると確信していますが、それらは大きなものだと思います。これで、既存のデータモデルや他の多くのことを処理するために、カスタムパスワード管理、2要素認証が必要になったときに、失い始めます。メンバーシップで提供されているコードは、何をしているのかわかっている場合、複製するのに数日かかることがあります。

それはあなたが望むことをしません。一見すると、すべてのニーズといくつかのニーズに対応できることがわかりますが、新しい要件が発生します。今、あなたは「本当に」このことの仕組みを学ばなければなりません。このすべてが事前に構築されていることの利点は、あなたがその誤った安全感覚にあったために減少します。

@Travisは既存のデータモデルを使用して言及しましたが、データベースの選択も制限になる可能性があります。

FacebookやGoogleなどのサードパーティの検証システムで動作するかどうかはわかりません。

多くの人がドキュメントをすぐに読んで考えるほど柔軟ではありませんが、彼らには場所があります。

ユーザートークンを制御する必要がなく、カスタム/拡張ユーザーデータまたはメンバーシップセットのみを構築する必要がある場合、または既存/異なるソースからそのデータを取得する必要がある場合。

それ以上変更したい場合は、認証プロバイダーの1つを実行するhttpmoduleを置き換えるほうが良い場合が多くあります。私がプロバイダーで物事を壊すことに遭遇したほとんどの人は、このレベルでの状況に対して間違った選択をしました。

どちらの方法でも、適切に設定されたcontext.userを取得するため、ほとんどのasp.netベースのユーザー機能を引き続き使用できます。

この質問は古いですが、人気があるためバッジを受け取っているので、更新された回答を提供する価値があると思います。

マイクロソフトの「シンプルな」メンバーシッププロバイダーは、私の謙虚な意見でようやく正しくなりました。新しいアプリケーションを作成する場合、または新しいアプリケーションでレガシーデータベースにアタッチする場合。シンプルなメンバーシッププロバイダーを使用します。簡単に実行できるクリーナー。いくつかのテーブルをインストールし、プロバイダーをユーザーのリストにポイントすると、基本的に完了です。

このリンクは、あなたを開始するか、単にグーグルで検索します：http : //www.mattjcowan.com/funcoding/2012/11/10/simplemembershipprovider-in-mvc4-for-mysql-oracle-and-more-with-llblgen/