7

ASP.NETMVCを既存のWebFormsアプリケーションに追加しています。この部分は既存のコード（フォーム認証）で処理されるため、当面は認証/ログインは気にしません。

既存のWebFormsアプリケーションでは、ページごとに完全にカスタムの権限ベースの承認があります。したがって、各ユーザーには一連の権限があり、アクセスが許可されているページが一覧表示されます。
次に、同じアクセス許可システムを使用して、特定のMVCコントローラーとアクションへのアクセスを制限する方法を決定する必要があります。

私が理解しているように、ASP.NET MVCには、役割を指定できる標準のAuthorizeAttributeがあります。また、ロールの代わりに権限を指定することを提案する記事もいくつか見つかりました。その場合、次のようなことを行うことができます。

[CustomAuthorize(Roles = "View products, Edit products")]

AuthorizeAttributeを拡張することで、アクセス許可を保存およびアクセスする方法を定義することもできます。

この解決策は私には受け入れられます（ただし、役割のセマンティクスを変更すると少し臭いがします）。
しかし、それにコミットする前に、他にどのようなオプションがあるかを確認したいと思います。そして、それは私が立ち往生しているところです-私はASP.NETMVCでの承認に関するさまざまなアプローチの本格的な概要を見つけていません。また、すべてのセキュリティ概念（フォーム認証、メンバーシッププロバイダー、承認属性、IPrincipalなど）が互いにどのように関連しているか、およびそれらがどのように連携するかについても知りたいと思います。

4

1 に答える 1

7

最初に理解する必要があるのは、Webformsと同様に、MVCにはパイプラインがあるということです。各リクエストはいくつかのメソッドを通過し、途中で「フックイン」して処理できる拡張ポイントがあります。

AuthorizeAttributeが行うのは、OnAuthorization拡張ポイントにフックし、指定した基準（ユーザー名、ロールなど）に基づいて、誰かにアクセスを許可するかどうかを決定することだけです。

次に例を示します：http：//geekswithblogs.net/brians/archive/2010/07/08/implementing-a-custom-asp.net-mvc-authorization-filter.aspx

独自のカスタム認証属性を作成し、独自の基準でまったく同じことを行うことができます。Rolesパラメーターを再利用する必要はありません。必要に応じて、独自のパラメーターをすべて作成できます。

これはMVCが好む方法です。もう1つの優れた点は、これもフィルターにすると、グローバルフィルターに追加して、必要に応じてすべてに適用できることです。

基本的に、他に2つの合理的な選択肢があります。Application_AuthenticateRequestのglobal.asaxにハンドラーを実装するか（非推奨）、OnAuthorizeをオーバーライドする共通のBaseControllerを作成します（属性は同じものをフックしますが、別の場所にあります）。

多くの人がSession変数を使用して認証を行おうとしますが、それは最悪のことです。

私たちはあなたの認証と許可システムについて何も知らないので、私たちにできることは一般的なアドバイスを提供することだけです。

于 2012-04-26T22:32:36.093 に答える