ASP.NET MVCの属性の承認

Question

ASP.NET MVCの[Authorize]属性の実際の使用を理解するのは難しいです。コンセプトに従えば、[Authorize]属性のコントローラーメソッドを装飾すると、認証されたユーザーだけがコントローラーにアクセスできます。

私は[Authorize]属性のコントローラーを装飾せずにASP.NET MVCアプリケーションを開発しました。私が見てきたことは、web.configなどのアプリケーションで認証メカニズムを適切に実装すると、特定のアクションメソッドのURL {controller}/{action}/{id}にアクセスできるようになりました。

システムは常にログインを求めます。つまり、私のコントローラは安全です。私の質問は、[Authorize]アトリビュートを使用せずにコントローラを保護することができるとき、それが本当に必要なのですか？

Answer 1

実力は、理解と実装のメンバーシップ・プロバイダーと一緒に役割プロバイダーと一緒に来ます。ユーザをロールに割り当てることができ、その制限に従って、ユーザごとに異なるアクションロールまたはコントローラ自体を適用することができます。

[Authorize(Users = "Betty, Johnny")] 
public ActionResult SpecificUserOnly() 
{ 
    return View(); 
} 

またはあなたがそれを使用する方が便利であるため、それが存在するグループ

[Authorize(Roles = "Admin, Super User")] 
public ActionResult AdministratorsOnly() 
{ 
    return View(); 
} 

Answer 2

に応じて制限することができ、また、それが許可パラメータではなく、XML設定をマークする属性を使用して全体の異なるイデオロギーです。それは汎用設定や他の認可フレームワーク、MVCのやり方だけに勝るものではありませんでした。私はこれを言っています。あなたが技術的な利点を探しているように思えるからです。

すでにBobRockに利点が記載されています。彼の答えに加えて、別のシナリオでは、アクションだけでなくコントローラ全体にこの属性を適用することができます。同じコントローラ内の異なるアクションに異なるロール認証パラメータを追加して組み合わせることもできます。

Answer 3

Authorize属性を使用すると、「MVC方法」の方がより便利に感じられます。技術的利点としてはいくつかあります。

あなたのアプリでアウトプットキャッシングを使用しているときに、私の頭に浮かべるシナリオがあります。 Authorize属性はそれをうまく処理します。

もう1つは拡張性です。 Authorizeの属性は、基本的なフィルタとしてそのまま使用できますが、そのメソッドをオーバーライドしたり、ログなどの事前承認動作を行うことができます。どのように設定すればよいか分かりません。

Answer 4

1つの利点は、アプリケーションへのアクセスをコンパイルしているため、Web.configを変更した人が誤って変更できないことです。

これは利点ではない場合があり、短所になる可能性があります。しかし、いくつかの種類のアクセスについては、それが好ましいことがあります。

さらに、Web.config内の認可情報がそれを汚染し、物を見つけるのが難しくなることがわかりました。だから、いくつかの点でその好み、他の方法ではそれを行う方法はありません。

Answer 5

[Authorize]を使用すると、アプリケーションのセキュリティホールを防ぐことができます。 MVCがURLを処理する方法（実際のファイルではなくコントローラにルーティングする）は、web.configファイルを使用してすべてを実際に安全にすることを困難にします。もっとここに

読む：answer.Butためhttp://blogs.msdn.com/b/rickandy/archive/2012/03/23/securing-your-asp-net-mvc-4-app-and-the-new-allowanonymous-attribute.aspx