在ASP.NET MVC中授权属性

我很难理解ASP.NET MVC中[Authorize]属性的实际用法。按照这个概念，如果我们用[Authorize]属性来装饰一个控制器方法，那么只有经过身份validation的用户才能访问控制器。

我开发了一个ASP.NET MVC应用程序，没有用[Authorize]属性装饰控制器。我所观察到的是，如果我在我的应用程序中使用web.config或其他方式正确实现身份validation机制，现在我可以访问特定操作方法的URL {controller}/{action}/{id} 。

系统总是要求login。这意味着我的控制器是安全的。我的问题是，当我可以保证我的控制器没有使用[Authorize]属性时，那么它的真正需求是什么？

真正的力量来自理解和实施会员提供者与angular色提供者。您可以将用户分配到angular色，并根据此限制，可以为不同的用户对控制器操作或控制器本身应用不同的访问angular色。

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

或者你可以按照组来限制

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

使用[Authorize]属性可以帮助防止应用程序中出现安全漏洞。 MVC处理URL的方式（即将它们路由到控制器而不是实际的文件）使得通过web.config文件实际上保护所有内容变得困难。

请阅读更多信息： http : //blogs.msdn.com/b/rickandy/archive/2012/03/23/securing-your-asp-net-mvc-4-app-and-the-new-allowanonymous-attribute。 ASPX

它的存在是因为使用起来更加方便，也是一个完全不同的使用属性标记授权参数而不是xmlconfiguration的思想体系。这并不意味着打败通用configuration或任何其他授权框架，只是MVC的做法。我这样说，因为看起来你正在寻找一个技术特点的优势，可能不是非常方便。

BobRock已经列出了优势。为了增加他的答案，另外一个场景是你可以把这个属性应用到整个控制器上，而不仅仅是动作，你也可以在同一个控制器的不同的动作中添加不同的angular色授权参数来混合和匹配。

使用Authorize属性似乎更方便，感觉更“MVC的方式”。至于技术优势还有一些。

我想到的一个场景是在应用程序中使用输出caching。很好的授权属性句柄。

另一个是可扩展性。 Authorize属性只是基本的框外filter，但你可以覆盖它的方法，并做一些预授权的行为，如日志等。我不知道你将如何做到这一点通过configuration。

一个好处是你正在编译访问应用程序，所以不会被修改Web.config的人改变。

这对你来说可能不是一个好处，也可能是一个缺点。但是对于某些访问来说，这可能是可取的。

另外，我发现Web.config中的授权信息污染了它，使得查找更难。所以在某些方面，它的偏好，在其他方面没有其他办法做到这一点。