我很难理解[Authorize]
ASP.NET MVC 中属性的实际使用.根据概念,如果我们使用[Authorize]
属性修饰控制器方法,则只允许经过身份验证的用户访问控制器.
我开发了一个ASP.NET MVC应用程序,没有用[Authorize]
属性装饰控制器.我观察到的是,如果我使用web.config或其他方式在我的应用程序中正确实现身份验证机制,那么我现在可以访问{controller}/{action}/{id}
特定操作方法的URL .
系统总是要求登录.这意味着我的控制器是安全的.我的问题是,当我可以在不使用[Authorize]
属性的情况下保护我的控制器时,它的真正需求是什么?
Bob*_*ock 87
真正的力量伴随着理解和实施成员资格提供者以及角色提供者.您可以将用户分配到角色,并根据该限制,您可以为不同的用户对控制器操作或控制器本身应用不同的访问角色.
[Authorize(Users = "Betty, Johnny")]
public ActionResult SpecificUserOnly()
{
return View();
}
Run Code Online (Sandbox Code Playgroud)
或者你可以根据团体限制
[Authorize(Roles = "Admin, Super User")]
public ActionResult AdministratorsOnly()
{
return View();
}
Run Code Online (Sandbox Code Playgroud)
Ale*_*ejo 14
使用[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
m0s*_*m0s 11
它的存在是因为它使用起来更方便,也是一种完全不同的意识形态,使用属性来标记授权参数而不是xml配置.它并不意味着击败通用配置或任何其他授权框架,只是MVC的方式.我这样说,因为看起来你正在寻找技术特征优势,可能不是......只是极好的便利性.
BobRock已经列出了优势.只是为了补充他的答案,另一种情况是您可以将此属性应用于整个控制器,而不仅仅是操作,还可以将不同的角色授权参数添加到同一控制器中的不同操作以进行混合和匹配.
使用Authorize
属性似乎更方便,感觉更"MVC方式".至于技术优势还有一些.
我想到的一个场景是你在应用程序中使用输出缓存.授权属性句柄很好.
另一个是可扩展性.该Authorize
属性只是基本的开箱即用过滤器,但您可以覆盖其方法并执行一些预授权操作,如日志记录等.我不知道您将如何通过配置执行此操作.
web.config 中的标签基于路径,而 MVC 使用控制器操作和路由。
如果您只是想阻止未登录的用户,但是当您尝试应用基于角色的授权以及您想要自定义处理未经授权的类型。
BobRock 的回答涵盖了第一种情况。
用户应至少具有以下角色之一才能访问控制器或操作
[Authorize(Roles = "Admin, Super User")]
Run Code Online (Sandbox Code Playgroud)
用户应该同时拥有这两个角色才能访问控制器或操作
[Authorize(Roles = "Super User")]
[Authorize(Roles = "Admin")]
Run Code Online (Sandbox Code Playgroud)
可以访问 Controller 或 Action 的用户是 Betty 和 Johnny
[Authorize(Users = "Betty, Johnny")]
Run Code Online (Sandbox Code Playgroud)
在 ASP.NET Core 中,您可以使用Claims和Policy原则通过[Authorize]
.
options.AddPolicy("ElevatedRights", policy =>
policy.RequireRole("Administrator", "PowerUser", "BackupAdministrator"));
[Authorize(Policy = "ElevatedRights")]
Run Code Online (Sandbox Code Playgroud)
第二个在较大的应用程序中非常方便,在这些应用程序中,可能需要根据情况使用不同的限制、流程和处理来实现授权。出于这个原因,我们可以扩展AuthorizeAttribute 并为我们的项目实现不同的授权替代方案。
public class CustomAuthorizeAttribute: AuthorizeAttribute
{
public override void OnAuthorization(AuthorizationContext filterContext)
{ }
}
Run Code Online (Sandbox Code Playgroud)
在 ASP.NET MVC 中进行授权的“正确完成”方式是使用该[Authorize]
属性。
一个优点是您正在编译对应用程序的访问,因此它不会被修改 Web.config 的人意外更改。
这对您来说可能不是优势,而可能是劣势。但是对于某些类型的访问,它可能更可取。
另外,我发现 Web.config 中的授权信息会污染它,并使查找内容变得更加困难。所以在某些方面是它的偏好,在其他方面没有其他方法可以做到。