2

既定の MVC3 アプリケーションでは、イントラネット プロジェクト テンプレートを使用する場合は Windows 認証が許可され、インターネット プロジェクト テンプレートの場合はフォーム認証が許可されます。私も利用したいサイトがあります。さらに、ユーザーを認証する独自のカスタムタイプの認証を使用する既存のサイトがあります (承認やロールはなく、識別のみです)。認証のためにレガシーシステムからのデータに加えて、それぞれの機能を使用する必要があるかもしれません。このため、認証を抽象化して分離する方法を決定しようとしています。完全に構成に基づいて、ある種の依存性注入を使用したいので、この同じサイトを 2 つの異なる場所にデプロイし、構成のみを変更することで認証モデル (Windows 認証/フォーム認証/カスタム認証) を切り替えることができます。

現在、MVC3 テンプレート プロジェクトを含む、私が扱ってきたすべての ASP.NET アプリケーションは、使用されている認証の種類と非常に密接に結びついているようです。

私はこれについて箱の外で考えすぎていますか?

これは可能ですか、またはこの密結合の理由はありますか?

更新 私が抱えている本当の問題は、一部のユーザーに使用する必要がある既存のレガシー認証と、他のユーザーに必要なフォーム認証の間にあります。Windows 認証とフォーム認証は、ログイン フォームが使用されていないため、実際には問題になりません。ただし、カスタム認証とフォーム認証を検討してください。LogIn フォームは、FormsAuthentication、より具体的には System.Web.Security と密接に結合されています。(つまり、Membership.ValidateUser、FormsAuthentication.SetAuthCookie など)。

FormsAuthentication と Membership を使用するのではなく、使用する認証を AccountController に注入したいと思います。

これまでのところ、私の問題が何であるかについて、これはより理にかなっていますか?

4

2 に答える 2

1

それらは実際にはそれほど緊密に結合されていません。テンプレートは、あなたをすぐに立ち上げて実行しようとしているだけです。

ASP.NETメンバーシップは、フォームとドメイン認証の両方をサポートします。

たとえば、Forms auth用に構成されたサイトでは、次のWeb.configような行が表示されます。

<authentication mode="Forms">

これを次のように変更できます。

<authentication mode="Windows">

これが唯一の違いではありませんが（Windows認証の場合、たとえば、ログインページは必要ありません）、最も重要です。ASP.NETメンバーシップAPIに基づいてコードを記述し、特に必要な場合にのみフォーム認証を対象とします。

于 2012-01-09T15:04:03.823 に答える
1

クレイグの答えに同意します。追加しなければならない唯一のことは、web.config で変更できるものはすべて疎結合であると考えているということです。その理由は、MVC アプリの展開パッケージを作成するときにweb.config 変換を適用できるためです。

DI/IoC には Unity を使用しており、Unity を使用して web.config でインジェクションの依存関係を指定することもできます。Web.Auth1.config を記述して、ある種類の認証用にアプリを構成し、Web.Auth2.config を別の種類の認証用に構成するだけです。次に、展開するときにターゲットを選択するだけで、VS が適切な構成を構築します。

展開で使用される認証の種類をソース コードで知る必要がある場合は、web.config appSetting を使用してそれを伝えることができます。これは、展開中に web.config 変換を使用して変更することもできます。

于 2012-01-09T15:23:30.760 に答える