大话设计，没有模式—通用权限设计与实现

当代码写多了，总有些是经验，但经验是什么呢？if…else用的次数比别人多？显然不是。有些超棒的设计能够谓之经验！

功能权限
网络上流行的经典的权限设计是【主体】- 【领域】 - 【权限】( who、what、how问题原型 ) 的设计思想，其中：

【主体】能够是用户，能够是角色，也能够是一个部门

【领域】能够是一个模块，能够是一个页面，也能够是页面上的按钮

【权限】能够是“可见”，能够是“只读”，也能够是“可用”(如按钮能够点击)

为了简化程序开发，在OpenAuth.Core中去掉了权限的控制，简化为【主体】- 【领域】的模式，且【主体】限定为角色。即只能给角色分配模块和按钮，不能直接分配给用户帐号或部门。且一旦分配即表示该角色拥有操做该模块（按钮）的权限。

大道至简，标准的RBAC规范比这个还要简洁，因此它的生命力才最顽强。在此基础上，若是进行二次开发，进行更详细的功能权限控制，能够按照上面的思想进行改造。

数据权限
数据权限是在功能权限的基础上面进一步的扩展，好比能够查看订单属于【功能权限】的范围，可是能够查看哪些订单就是【数据权限】的工做了。

这里面的几个概念：

【资源】：数据权限的控制对象，业务系统中的各类资源。好比订单单据、销售单等。

【数据规则】：用于数据权限的条件规则 。

应用场景

销售单，能够由本人查看
销售单，测试角色能看到本身的订单
销售单，测试角色能看到本身的订单，管理员角色能够看到全部订单
销售单，测试角色能看到本身的订单，管理员角色能够看到全部订单，帐号test3能够看到应用名称为"xxx管理系统"的订单
咱们能想到直接的方法，在访问数据的入口加入SQL Where条件来实现，以上4种状况对应的sql语句：

1 where CreateUserID = {loginUser}
 2 where CreateUserID = {loginUser} and {loginRole} in (测试）
 3 where CreateUserID = ({loginUser} and {loginRole} in (测试)) or {loginRole} in (管理员)
 4 where CreateUserID = ({loginUser} and {loginRole} in (测试)) or {loginRole} in (管理员)or ({loginUser}==test3 and 应用名称==XXX管理系统)

这些一个一个的"条件"，简单理解为一个【数据规则】，一般会与原来咱们前台的业务过滤条件合并再检索出数据。

每个角色有不同的【数据规则】，那么数据权限设计就变成

【资源】 - 【数据规则】

在数据库记录中存放为资源ID+规则的形式，以下：

为了简化程序开发，在开发过程当中能够作出如下约定：

全部须要进行数据权限控制功能的表，在设计时必须包含字段CreateUserId（建立用户Id)。
【资源】的名称限定为模块名称。如部门管理，用户管理，那么资源就是对应的部门列表，用户列表。
若是【资源】没有设置数据规则，那么视为该资源容许被任何主体查看。
数据规则中受权的对象限定为角色、用户。即不能设定为某个部门全部，若是想实现相似的功能，经过角色间接实现。例如：资源属于角色“开发组成员”，“开发组组长”。

核心实现--查询对象模式
权限控制总离不开一些条件的限制，若是没有完善的查询机制，那么在作权限条件过滤的时候你会以为很别扭。马丁在《企业应用架构模式》第13章对象-关系元数据映射模式中提出查询对象模式(Query Object Pattern)。该模式核心结构以下：

该结构为【数据规则】的创建提供了理论基础。在设计数据权限的时候，能够照搬该思想。上面例子中的规则，数据规则展开以下：

1 {
 2  "Operation": "or",
 3  "Filters": [{
 4      "Key": "{loginRole}",
 5      "Value": "09ee2ffa-7463-4938-ae0b-1cb4e80c7c13",
 6      "Contrast": "contains",
 7      "Text": "管理员"
 8  }],
 9  "Children": [{
 10         "Operation": "and",
 11         "Filters": [{
 12             "Key": "{loginRole}",
 13             "Value": "0a7ebd0c-78d6-4fbc-8fbe-6fc25c3a932d",
 14             "Contrast": "contains",
 15             "Text": "测试"
 16         }, {
 17             "Key": "CreateUserId",
 18             "Value": "{loginUser}",
 19             "Contrast": "==",
 20             "Text": ""
 21         }]
 22     }, {
 23         "Operation": "and",
 24         "Filters": [{
 25             "Key": "AppName",
 26             "Value": "XXX管理平台",
 27             "Contrast": "==",
 28             "Text": ""
 29         }, {
 30             "Key": "{loginUser}",
 31             "Value": "229f3a49-ab27-49ce-b383-9f10ca23a9d5,1df68dfd-3b6d-4491-872f-00a0fc6c5a64",
 32             "Contrast": "in",
 33             "Text": "test3,test4"
 34         }]
 35     }]
 36 }

规则分为三个部分：【分组】(Children)、【规则】(Filter)、【操做符】(and or)，而规则自身就是一个分组。这种简单的结构就能够知足所有的状况。看不懂啥意思？

这样理解起来就比较简单了。

还不懂？？咱们从简单的开始：

某一角色只能看到本身建立的信息。如：针对资源列表，咱们设置了【测试】角色能够看到本身建立的资源。

这时若是用一个拥有测试角色的帐号（test）登陆，那么他只能看到本身建立的资源：

其余角色的帐号登陆时，会出现没法看到任何信息。咱们稍作调整：【管理员】角色能够看到全部资源，【测试】角色只能看到本身建立的资源。

这时若是用一个拥有管理员角色的帐号（admin）登陆，那么他就能够看到所有资源：

以此为基础，咱们能够扩展很是复杂的数据权限控制。最终造成最后的复杂规则：【管理员】角色能够看到全部资源，【测试】角色只能看到本身建立的资源。帐号test3/test4只能看到应用名称等于“XXX管理平台”的资源。

代码解析--不要BB，秀出你的代码
能够在应用层基类BaseApp中，定义一个通用函数，根据当前即将访问的资源Id获取相应的访问【数据规则】，并把当前登陆的用户信息注入到该规则中，最终转换成针对数据库的查询，以下：（不想看这个？直接跳过吧，看看如何使用也没有问题）

1 protected IQueryable<T> GetDataPrivilege(string parametername)
 2 {
 3 var loginUser = _auth.GetCurrentUser();
 4 if (loginUser.User.Account == Define.SYSTEM_USERNAME) return UnitWork.Find<T>(null); //超级管理员特权
 5 
 6 var moduleName = typeof(T).Name;
 7 var rule = UnitWork.FindSingle<DataPrivilegeRule>(u => u.SourceCode == moduleName);
 8 if (rule == null) return UnitWork.Find<T>(null); //没有设置数据规则，那么视为该资源容许被任何主体查看
 9 if (rule.PrivilegeRules.Contains(Define.DATAPRIVILEGE_LOGINUSER) ||
 10 rule.PrivilegeRules.Contains(Define.DATAPRIVILEGE_LOGINROLE))
 11 {
 12 
 13 //即把{loginUser} =='xxxxxxx'换为 loginUser.User.Id =='xxxxxxx'，从而把当前登陆的用户名与当时设计规则时选定的用户id对比
 14 rule.PrivilegeRules = rule.PrivilegeRules.Replace(Define.DATAPRIVILEGE_LOGINUSER, loginUser.User.Id);
 15 var roles = loginUser.Roles.Select(u => u.Id).ToList();
 16 roles.Sort(); //按字母排序,这样能够进行like操做
 17 rule.PrivilegeRules = rule.PrivilegeRules.Replace(Define.DATAPRIVILEGE_LOGINROLE,
 18 string.Join(',',roles));
 19 }
 20 return UnitWork.Find<T>(null).GenerateFilter(parametername,
 21 JsonHelper.Instance.Deserialize<FilterGroup>(rule.PrivilegeRules));
 22 }
这样在咱们本身的应用中，使用上面的函数建立一个基础查询，再加上自定义的查询条件便可轻松实现数据权限的控制。

 1 var result = new TableData();
 2 var objs = GetDataPrivilege("u");
 3 if (!string.IsNullOrEmpty(request.key))
 4 {
 5 objs = objs.Where(u => u.Id.Contains(request.key));
 6 }
 7 
 8 result.data = objs.OrderBy(u => u.Id)
 9 .Skip((request.page - 1) * request.limit)
 10 .Take(request.limit);

最后
以上全部代码均已实现并开源（配置数据规则的界面能够本身画，layui的前端画起来实在太费力），OpenAuth.Core秉承代码之美，为.net core添砖加瓦，喜欢的star一下！

以为不错的话点个关注哦