我正在阅读有关 Web Api 授权的多个资源（书籍和一些答案）。
假设我想添加仅允许某些用户访问的自定义属性：
Case #1
我见过这种方法压倒性的 OnAuthorization，如果出现问题，它会设置响应
public class AllowOnlyCertainUsers : AuthorizeAttribute
{
public override void OnAuthorization(HttpActionContext actionContext)
{
if ( /*check if user OK or not*/)
{
actionContext.Response = new HttpResponseMessage(HttpStatusCode.Unauthorized);
}
}
}
Case #2
但我也见过这个类似的例子，它也是最重要的OnAuthorization但打电话给base :
public override void OnAuthorization(HttpActionContext actionContext)
{
base.OnAuthorization(actionContext);
// If not authorized at all, don't bother
if (actionContext.Response == null)
{
//...
}
}
然后，您检查是否HttpActionContext.Response是否设置。如果不设置，则表示请求已授权，用户ok
Case #3
但我也见过这种重写方法IsAuthorized :
public class AllowOnlyCertainUsers : AuthorizeAttribute
{
protected override bool IsAuthorized(HttpActionContext context)
{
if ( /*check if user OK or not*/)
{
return true;// or false
}
}
}
Case #4
然后我看到了类似的示例一，但调用了 base.IsAuthorized(context) ：
protected override bool IsAuthorized(HttpActionContext context)
{
if (something1 && something2 && base.IsAuthorized(context)) //??
return true;
return false;
}
还有一件事
最后多米尼克说here :
您不应该覆盖 OnAuthorization - 因为您将缺少 [AllowAnonymous] 处理。
问题
1）我应该使用哪些方法：IsAuthorized or OnAuthorization？ （或何时使用哪个）
2）我什么时候应该打电话base.IsAuthorized or基础.OnAuthorization` ?
3）他们就是这样建造的吗？如果响应为空那么一切都好？ （案例#2）
NB
请注意，我仅使用（并且想要使用）AuthorizeAttribute它已经继承自AuthorizationFilterAttribute
Why ?
因为我正处于第一阶段：http://www.asp.net/web-api/overview/security/authentication-and-authorization-in-aspnet-web-api
无论如何，我通过扩展 Authorize 属性来询问。
我应该使用哪些方法：IsAuthorized 或 OnAuthorization？ （ 或者 何时使用哪个）
你将延长AuthorizationFilterAttribute如果您的授权逻辑不依赖于已建立的身份和角色。对于用户相关的授权，您将扩展并使用AuthorizeAttribute。对于前一种情况，您将覆盖OnAuthorization。对于后一种情况，您将覆盖IsAuthorized。从这些属性的源代码中可以看到，OnAuthorization如果您派生自，则标记为虚拟供您覆盖AuthorizationFilterAttribute。另一方面，IsAuthorized方法被标记为虚拟的AuthorizeAttribute。我相信这是一个很好的指向预期用途的指针。
我什么时候应该调用base.IsAuthorized或base.OnAuthorization？
这个问题的答案在于面向对象的一般工作方式。如果您重写一个方法，您可以完全提供一个新的实现，也可以利用父级提供的实现来增强行为。例如，以IsAuthorized(HttpActionContext)。基类行为是根据过滤器中指定的内容与建立的身份来检查用户/角色。比如说，您想要执行所有这些操作，但除此之外，您还想检查其他内容，可能基于请求标头或其他内容。在这种情况下，您可以提供这样的覆盖。
protected override bool IsAuthorized(HttpActionContext actionContext)
{
bool isAuthroized = base.IsAuthorized(actionContext);
// Here you look at the header and do your additional stuff based on actionContext
// and store the result in isRequestHeaderOk
// Then, you can combine the results
// return isAuthorized && isRequestHeaderOk;
}
抱歉，我不明白你的问题 3。顺便说一句，授权过滤器已经存在很长时间了，人们将它用于各种各样的事情，有时甚至是错误的。
还有一件事。最后这里有个家伙说：你 不应该覆盖 OnAuthorization - 因为你会丢失 [AllowAnonymous] 处理。
说这句话的人就是访问控制之神——多米尼克。显然这是正确的。如果你看一下实施OnAuthorization（复制如下），
public override void OnAuthorization(HttpActionContext actionContext)
{
if (actionContext == null)
{
throw Error.ArgumentNull("actionContext");
}
if (SkipAuthorization(actionContext))
{
return;
}
if (!IsAuthorized(actionContext))
{
HandleUnauthorizedRequest(actionContext);
}
}
打电话给SkipAuthorization是确保的部分AllowAnonymous应用过滤器，即跳过授权。如果您重写此方法，您就会失去该行为。实际上，如果您决定将授权基于用户/角色，那么您将决定从AuthorizeAttribute。此时您唯一剩下的正确选择就是覆盖IsAuthorized而不是已经被覆盖的OnAuthorization，尽管技术上两者都是可行的。
附言。在 ASP.NET Web API 中，还有另一个过滤器，称为身份验证过滤器。想法是，您使用它进行身份验证，并使用授权过滤器进行授权，如名称所示。然而，有很多例子表明这个界限是被捏造的。许多授权过滤器示例都会进行某种身份验证。无论如何，如果你有时间并且想了解更多，请看一下这个 MSDNarticle。免责声明：这是我写的。