1、CommonAuthorize: IAuthorizationRequirement，至于取什么名字，自己定义，但必须继承IAuthorizationRequirement，这类主要是承载一些初始化值，让后传递到Handler中去，给验证做逻辑运算提供一些可靠的信息；我这里是空的；自己根据自身情况自己定义适当的属性作为初始数据的承载容器；
2、CommonAuthorizeHandler : AuthorizationHandler<CommonAuthorize>这个是重点，承载了验证的逻辑运算
需要重写override Task HandleRequirementAsync方法，所有的逻辑都在该方法中，他的主要逻辑和上面的自定义中间件很相似，只少了上面的第一步；验证流程如下：
获取当前http头部携带的jwt（存放在头部的 Authorization中）；
使用上一节的讲的TokenContext做必须的验证和自定义复杂验证；
获取当前访问用户信息，我们把用户的基本信息放在payLoad["ruser"中，请看代码如何操作
到这里为止，都是做的身份验证，表明你是一个有身份的的人；接下来是做权限验证，你是一个有身份的人，并不代表你是一个随便到处访问的人；你能访问哪些url或者action，就要得到权限验证的认可
我们把权限验证放到 userContext.Authorize方法中（这里怎么操作，这里就不深入讲解，基本原理是从数据库或者缓存中获取当前用户对应的权限列表，也就是url列表，进行对比）;
context.Succeed(requirement);是验证成功，如果没有这个，就默认验证失败
因为UserContext把负责了权限验证，所以不会把流程搞得感觉很乱，并且可以重用，至于用那种形式验证也很容易切换
3、是不是很简单，和自定义管道验证的的代码几乎一模一样，
如何使用自定义定义策略呢？
1、在startup类中的ConfigureServices中加入如下代码：
services.AddAuthorization(option => { #region 自定义验证策略 option.AddPolicy("common", policy => policy.Requirements.Add(new CommonAuthorize())); #endregion }).AddAuthentication(option => { option.DefaultScheme = JwtBearerDefaults.AuthenticationScheme; }).AddJwtBearer(option => { if (!string.IsNullOrEmpty(config["JwtOption:SecurityKey"])) { TokenContext.securityKey = config["JwtOption:SecurityKey"]; } //设置需要验证的项目 option.TokenValidationParameters = new TokenValidationParameters { IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(TokenContext.securityKey))//拿到SecurityKey }; }); //自定义策略IOC添加 services.AddSingleton<IAuthorizationHandler, CommonAuthorizeHandler>();
以上代码主要分3个部分
1、添加上面自定义的策略，并取名；
2、设置秘钥，这个秘钥就是上一节中生成jwt的秘钥，必须要要一样，否则是签名不正确
3、注入上面建立的一个重要类CommonAuthorizeHandler，如上面代码
2、在startup类中的Configure中添加 app.UseAuthentication();
3、在需要验证的Controller或者Action中加上[Authorize(Policy = "common")]属性，看下图：
到此为止你就可以使用自定义策略的验证了；
使用管道和自定义策略两种形式进行验证有什么区别呢?
从效果上看都是一样的，稍微有点区别
使用管道的方式，感觉方便点，清晰点