问题描述
在ASP.Net Web API 2(Owin)中,IAuthenticationFilter
和AuthorizeAttribute
有什么区别?
In ASP.Net Web API 2 (Owin), what is the difference between IAuthenticationFilter
and AuthorizeAttribute
?
目前,我已经通过创建自己的AuthorizeAttribute
来实现我的授权:
Currently I have implemented my authorization by creating my own AuthorizeAttribute
like this:
public class IntegratedAuthorization : AuthorizeAttribute
{
protected override bool IsAuthorized(System.Web.Http.Controllers.HttpActionContext actionContext)
{
bool returnValue = false;
if (actionContext.Request.Headers.Authorization != null)
{
if (actionContext.Request.Headers.Authorization.Scheme != null)
{
if (actionContext.Request.Headers.Authorization.Scheme.ToLower() == "basic")
{
if (actionContext.Request.Headers.Authorization.Parameter != null)
{
// ....
// ....
// ....
}
}
}
}
return returnValue;
}
}
比起我将它添加到我的HttpConfiguration
中
Than I have added it to my HttpConfiguration
like this:
config.Filters.Add(new IntegratedAuthorization());
一切正常,但是当我搜索Internet时,发现很多使用IAuthenticationFilter
的开发人员,例如本教程: ASP.NET Web API 2中的身份验证过滤器.
Everything works fine, but when I searched the Internet, I found a lot of developers, who use IAuthenticationFilter
, like in this tutorial: Authentication Filters in ASP.NET Web API 2.
现在真正的问题是,这两种方法有什么区别?我该怎么用?
Now the real question, what is the difference between this two methods? What should I use?
谢谢!
推荐答案
AuthorizeAttribute
是要实现的用于授权应用程序的类.您正在使用正确的方法.
AuthorizeAttribute
is the class to implement for authorization of an application. You are following the correct approach.
IAuthorizationFilter
是许多过滤器实现的更通用的接口,但不一定都提供授权.尽管MVC不在乎一种或另一种方式,但是 唯一方式 的第三方库可以识别应用程序中的授权组件,因此插入应用程序的安全性是为了检查它是否继承AuthorizeAttribute
.底线是,如果您的授权组件未继承AuthorizeAttribute
,则某些第三方库可能在您的应用程序中无法正常运行.
IAuthorizationFilter
is a more generalized interface that many filters implement, but they don't necessarily all provide authorization. While MVC doesn't care much one way or the other, the only way 3rd party libraries can identify the authorization component in the application and thus plug into the application's security is to check whether it inherits AuthorizeAttribute
. The bottom line is that if your authorization component doesn't inherit AuthorizeAttribute
, some 3rd party libraries might not function correctly in your application.
由于AuthorizeAttribute
实现了IAuthorizationFilter
,因此您仍然可以访问其所有功能,包括Farhad提到的OnAuthorization
方法.
Since AuthorizeAttribute
implements IAuthorizationFilter
, you still have access to all of its functionality, including the OnAuthorization
method that Farhad mentioned.
唯一的缺点是Microsoft假定通过将AuthorizeAttribute
的这些属性制成,每个应用程序都将基于用户和角色.因此,如果您有一个没有的应用程序,则可能需要在实现中隐藏这些属性.
The only downside is Microsoft assumed that every application would be based on users and roles by making these properties of AuthorizeAttribute
. So, if you have an application that is not, you may need to hide these properties in your implementation.
[Obsolete("Not applicable in this class.")]
[DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
[Browsable(false), EditorBrowsable(EditorBrowsableState.Never)]
new public string Roles { get; set; }
[Obsolete("Not applicable in this class.")]
[DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
[Browsable(false), EditorBrowsable(EditorBrowsableState.Never)]
new public string Users { get; set; }
第三方需要一个附加的约束来插入应用程序安全性-如果您覆盖OnAuthorization
(请注意,不必这样做),则对于actionContext.Response
而言,成功的授权返回null
非常重要属性和不成功的授权必须将其设置为非null值(处理程序将基于失败进行操作).这是默认实现的工作方式,如果需要对其进行自定义,则应遵循相同的模式.
One additional constraint is required for 3rd parties to plug into your application security - if you override OnAuthorization
(note that you don't have to) it is important that a successful authorization return null
for the actionContext.Response
property and an unsuccessful authorization must set it to a non-null value (a handler that will take action based on the failure). This is the way the default implementation works, and you should follow the same pattern if you need to customize it.
这篇关于AuthorizeAttribute和IAuthenticationFilter之间的区别的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!