公開されているWebサイトに、すぐに使用できるaspnetメンバーシッププロバイダー、アカウントコントローラー、データベーススキーマなど(ootbログイン/登録システム全体)を使用しても大丈夫かどうか疑問に思いました。
- 不要なものがたくさんあることは知っていますが、最初から作成する必要がないので時間を節約したいと思います。
- カスタムニーズに合わせて拡張することを明確に計画しています
脆弱性はありますか、それともユーザーをそれから遠ざける不要なものがたくさんあるという事実だけですか?
公開されているWebサイトに、すぐに使用できるaspnetメンバーシッププロバイダー、アカウントコントローラー、データベーススキーマなど(ootbログイン/登録システム全体)を使用しても大丈夫かどうか疑問に思いました。
脆弱性はありますか、それともユーザーをそれから遠ざける不要なものがたくさんあるという事実だけですか?
私の最後のプロジェクトでは、WIFベースのソリューションを支持してメンバーシップを破棄しました。認証時に、ユーザーIDを含む暗号化されたセッションCookieを作成し、後でSessionAuthenticationModuleを使用してCookieからプリンシパルを設定します。魅力のように機能し、データベースとユーザーストレージを完全に制御できます。また、ActsAs、Federationなどの複雑なものも許可
されます。公開サイトの場合は、自動登録を使用してOAuthのものを追加することもできます。独自のストレージスキーマを使用すると、はるかにクリーンになります。また、メンバーシップによってRBACタイプの許可が決まります。個人的には、単純なIsInRoleだけで問題がなかったプロジェクトを見たことがありません。
これは単なるIMHOです=)また、.Net4.5ではコアにWIFが含まれることに注意してください。