自定义授权在Asp.net的WebAPI - 什么乱七八糟的？ [英] Custom Authorization in Asp.net WebApi - what a mess?

问题描述

的我从几个资源（书籍等答案）关于授权读取的WebAPI。的

假设我想添加自定义属性，只允许特定用户访问：

案例＃1

我见过这种方法的覆盖的 OnAuthorization ，这台响应，如果事情是错的。

 公共类AllowOnlyCertainUsers：AuthorizeAttribute
{
 公共覆盖无效OnAuthorization（HttpActionContext ActionContext中）
  {
   如果（/ *检查用户是否确定或不* /）
   {
     actionContext.Response =新的Htt presponseMessage（的HTTPStatus code.Unauthorized）;
   }
  }
}
 

案例＃2

不过，我也看到了这个类似的例子也覆盖 OnAuthorization 而是打电话给基：

 公共覆盖无效OnAuthorization（HttpActionContext ActionContext中）
{
  base.OnAuthorization（ActionContext中）;    //如果在所有未经授权，请勿打扰    如果（actionContext.Response == NULL）
     {
      // ...
     }
}
 

的然后，您检查
HttpActionContext.Response 设置与否。如果它没有置位，它意味着该请求被授权，并且用户是确定的

案例＃3

不过，我也看到了覆盖 IsAuthorized 的这种方式：

 公共类AllowOnlyCertainUsers：AuthorizeAttribute
{
 保护覆盖布尔IsAuthorized（HttpActionContext上下文）
  {
   如果（/ *检查用户是否确定或不* /）
   {
    返回true; //或false
   }
  }
}
 

案例＃4

然后，我看到类似的例子之一，但与调用base.IsAuthorized（上下文）：

 保护覆盖布尔IsAuthorized（HttpActionContext上下文）
{
 如果（something1＆放大器;＆放大器; something2＆放大器;＆放大器; base.IsAuthorized（上下文））// ??
 返回true;
 返回false;
}
 

的一件事的

最后多米尼克说：<一href=\"http://stackoverflow.com/questions/15148050/custom-authorizations-in-web-api#comment-21417166\">here

的你不应该重写OnAuthorization - 因为你会错过[使用AllowAnonymous]处理的

。

问题

• 1）我应该使用哪种方法： IsAuthorized 或 OnAuthorization ？ （或当要使用的）




• 2）时，我应该叫 base.IsAuthorized或 base.OnAuthorization`？




• 3）这一点，他们如何建造它是什么？如果响应为null，则一切正常？ （案例＃2）

NB

请注意，我使用（并希望使用）仅 AuthorizeAttribute 这已经从 AuthorizationFilterAttribute <继承/ p>

为什么？

监守我在第一阶段：<一href=\"http://www.asp.net/web-api/overview/security/authentication-and-authorization-in-aspnet-web-api\">http://www.asp.net/web-api/overview/security/authentication-and-authorization-in-aspnet-web-api

反正林通过延长授权的属性要求。

解决方案

  

我应该使用哪种方法：IsAuthorized或OnAuthorization？ （ 要么
  时使用的）

您将延长 AuthorizationFilterAttribute 如果你的授权逻辑是不依赖于建立的身份和角色。对于用户相关的授权，您将扩展并使用 AuthorizeAttribute 。对于前一种情况下，你将覆盖 OnAuthorization 。对于后一种情况，你将覆盖 IsAuthorized 。正如你可以从这些属性的源$ C ​​$ C看到， OnAuthorization 标记虚拟为你如果从派生覆盖 AuthorizationFilterAttribute 。在另一方面， IsAuthorized 方法是在 AuthorizeAttribute 标记虚。我相信这是一个很好的指针设计用途。

  

当我应该叫base.IsAuthorized或base.OnAuthorization？

在这个问题的答案在于如何OO工作一般。如果重写一个方法，你可以完全提供新的实施或驮回母公司提供的实现和提升行为。例如，以 IsAuthorized的情况下（HttpActionContext）。基类行为是检查针对什么是在过滤器VS建立的标识指定的用户/角色。再说了，你想要做的，此外，要检查其他的东西，但所有这一切，可能是基于一个请求头什么的。在这种情况下，你可以提供一个覆盖这个样子。

 保护覆盖布尔IsAuthorized（HttpActionContext ActionContext中）
{
    布尔isAuthroized = base.IsAuthorized（ActionContext中）;
    //在这里，你看标题，并根据ActionContext中做你的额外的东西
    //和结果存储在isRequestHeaderOk
    //然后，你可以结合的结果
    //返回isAuthorized＆放大器;＆安培; isRequestHeaderOk;
}
 

我很抱歉，但不明白你的Q3。 BTW，授权过滤器已经存在了很长一段时间，人们使用它的各种东西，有时不正确的为好。

  

一件事。终于有这个家伙在这里谁说​​：你
  不应该重写OnAuthorization - 因为你会错过
  [使用AllowAnonymous]处理。

谁说，这就是访问控制的神的家伙 - 多米尼克。很显然，这将是正确的。如果你看一下实施 OnAuthorization （下复制），

 公共覆盖无效OnAuthorization（HttpActionContext ActionContext中）
{
    如果（ActionContext中== NULL）
    {
        扔Error.ArgumentNull（ActionContext中）;
    }    如果（SkipAuthorization（ActionContext中））
    {
        返回;
    }    如果（！IsAuthorized（ActionContext中））
    {
        HandleUnauthorizedRequest（ActionContext中）;
    }
}
 

调用 SkipAuthorization 是确保使用AllowAnonymous 过滤器应用，也就是授权跳过的部分。如果覆盖此方法，你失去这种行为。其实，如果你决定要立足于用户/角色的授权，在这一点上，你会决定从 AuthorizeAttribute 派生。只有在这一点留给你正确的选项将覆盖 IsAuthorized ，而不是已经覆盖 OnAuthorization ，虽然它是技术上可以做到无论是。

PS。在ASP.NET的Web API，有一个叫认证过滤另一个过滤器。想法是，你使用的身份验证和授权过滤器授权，顾名思义。然而，有很多，其中该边界是捏造的例子。的authroization过滤器的例子很多会做一些种类的认证。不管怎么说，如果你有时间，想了解多一点，看看这个MSDN 文章。免责声明：它是我写的

I'm reading from several resources (books and SO answers) about authorization in WebApi.

Suppose I want to add Custom Attribute which allows access only for Certain Users:

Case #1

I've seen this approach of overriding OnAuthorization , which sets response if something is wrong

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

But I've also seen this similar example which also overriding OnAuthorization but with calling to base :

public override void OnAuthorization(HttpActionContext actionContext) 
{ 
  base.OnAuthorization(actionContext);

    // If not authorized at all, don't bother

    if (actionContext.Response == null)  
     {
      //...
     }
}

Then, you check if the HttpActionContext.Response is set or not. If it’s not set, it means that the request is authorized and the user is ok

Case #3

But I've also seen this approach of overriding IsAuthorized :

public class AllowOnlyCertainUsers : AuthorizeAttribute
{
 protected override bool IsAuthorized(HttpActionContext context)
  {
   if ( /*check if user OK or not*/)
   {
    return true;// or false
   }
  }
}

Case #4

And then I saw similar example one but with calling base.IsAuthorized(context) :

protected override bool IsAuthorized(HttpActionContext context)
{
 if (something1 && something2 && base.IsAuthorized(context)) //??
 return true;
 return false;
}

One more thing

And finally Dominick said here :

You shouldn't override OnAuthorization - because you would be missing [AllowAnonymous] handling.

Questions

• 1) Which methods should I use : IsAuthorized or OnAuthorization ? ( or when to use which)

• 2) when should I call base.IsAuthorized or base.OnAuthorization` ?

• 3) Is this how they built it ? that if the response is null then everything is ok ? ( case #2)

NB

Please notice , I'm using ( and want to use ) only AuthorizeAttribute which already inherits from AuthorizationFilterAttribute

Why ?

Becuase I'm at the first stage in : http://www.asp.net/web-api/overview/security/authentication-and-authorization-in-aspnet-web-api

Anyway Im asking via extending Authorize attribute .

解决方案

Which methods should I use : IsAuthorized or OnAuthorization ? ( or when to use which)

You will extend AuthorizationFilterAttribute if your authorization logic is not dependent on the identity established and roles. For user related authorization, you will extend and use AuthorizeAttribute. For the former case, you will override OnAuthorization. For the latter case, you will override IsAuthorized. As you could see from the source code of these attributes, OnAuthorization is marked virtual for you to override if you derive from AuthorizationFilterAttribute. On the other hand, the IsAuthorized method is marked virtual in AuthorizeAttribute. I believe this is a good pointer to the intended usage.

when should I call base.IsAuthorized or base.OnAuthorization?

The answer to this question lies in how OO generally works. If you override a method, you can either completely provide a new implementation or piggy back on the implementation provided by parent and enhance the behavior. For example, take the case of IsAuthorized(HttpActionContext). The base class behavior is to check the user/role against what is specified in the filter vs the identity established. Say, you want to do all that but in addition, you want to check something else, may be based on a request header or something. In that case, you can provide an override like this.

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;
}

I'm sorry but don't understand your Q3. BTW, Authorization filter has been around for a long time and people use it for all kinds of things and sometimes incorrectly as well.

One more thing. And finally there was this guy here who said : You shouldn't override OnAuthorization - because you would be missing [AllowAnonymous] handling.

The guy who said that is the God of access control - Dominick. Obviously it will be correct. If you look at the implementation of OnAuthorization (copied below),

public override void OnAuthorization(HttpActionContext actionContext)
{
    if (actionContext == null)
    {
        throw Error.ArgumentNull("actionContext");
    }

    if (SkipAuthorization(actionContext))
    {
        return;
    }

    if (!IsAuthorized(actionContext))
    {
        HandleUnauthorizedRequest(actionContext);
    }
}

the call to SkipAuthorization is the part that ensures AllowAnonymous filters are applied, that is, authorization is skipped. If you override this method, you loose that behavior. Actually, if you decide to base your authorization on users/roles, at that point you would have decided to derive from AuthorizeAttribute. Only correct option left for you at that point will be to override IsAuthorized and not the already overridden OnAuthorization, although it is technically possible to do either.

PS. In ASP.NET Web API, there is another filter called authentication filter. Idea is that you use that for authentication and authorization filter for authorization, as the name indicates. However, there are lots of examples where this boundary is fudged. Lots of authroization filter examples will do some kind of authentication. Anyways, if you have time and want to understand a bit more, take a look at this MSDN article. Disclaimer: It was written by me.

这篇关于自定义授权在Asp.net的WebAPI - 什么乱七八糟的？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！