但凡业务系统，授权是绕不开的一环。见过太多只在前端做菜单及按钮显隐控制，但后端裸奔的，觉着前端看不到，系统就安全，掩耳盗铃也好，自欺欺人也罢，这里不做评论。在.NET CORE中，也见过不少用操作过滤器来实现业务用例权限控制的，至少算是对后端做了权限控制。
但我们知道，操作过滤器，已经算是过滤器管道中最靠后的，基本上紧挨着我们控制器方法执行那里了，本身，操作过滤器也不是做权限控制的地方，虽然本身它能达到权限控制效果。为什么这么说，试想下，在过滤器管道之前，还有中间件处理管道，即便是过滤器管道执行环节，操作过滤器也是最靠后的，它往前还有授权过滤器，资源过滤器等，假如我在资源过滤器中缓存了请求结果，那权限控制基本上就废了。
说这么多，只想表达一点，合适的地方，合适的东西，干合适的事儿。在.NET CORE中，官方推荐用策略去实现授权。策略授权，是在授权中间件环节执行，当然能解决上述执行流程先后顺序的问题。但如果要直接应用于我们业务系统中的权限控制，恐怕远远不够，因为你不可能为每个api用例创建一个角色或策略，更主要的，权限控制还要动态授予或回收的，不做扩展直接照搬，你是很难搞的。接下来，我们就来看看，如何基于core的授权机制，去实现我们传统的用户，角色，权限，及权限的动态授予与回收控制。
2、实现
我们先看看，菜单表概览：
查询中IsMenu代表是侧边栏菜单还是功能按钮，这里我把按钮级别的给筛选出来了，每个按钮菜单都代表一个业务用例，也对应我们一个控制器方法。 Code是唯一的，待会儿权限控制标识，会采用这个字段。当然你用主键ID也可以，但比较难记。实际运维中，会把这些菜单按照业务分配给指定角色，再把指定角色分配给系统用户。
接下来，定义一个Requirement，以权限码作为主校验对象：
public class PermissionRequirement : IAuthorizationRequirement { public PermissionRequirement(params string[] codes) { this.Codes = codes; } public string[] Codes { get; private set; } }