通用数据权限的思考与设计-APP开发 软件开发 APP开发公司 软件开发公司

APP开发 软件开发 APP开发公司 软件开发公司

?1、数据权限概述
?1.1、什么是数据权限？
?数据权限是指对系统用户对数据资源可见性的控制。流行的解释是，满足某种条件的用户只能在该条件下看到相应的数据资源。所以最简单的数据权限可能是：用户只能看到自己的数据。在正式的系统环境中，有许多更复杂的数据权限需求方案，例如：
?领导需要看到所有下属员工的客户数据，员工只能看到自己的客户数据；
?经理A可以看到所有企业客户，B经理只能看到企业客户年销售额不到1000万；
?a角色可以看到全国的产品数据，B角色只能看到上海的产品数据；
?这些要求也可以通过使用硬编码实现，但是在业务的快速发展过程中，对于类似的数据权限将有越来越多的要求。如果所有这些要求都是硬编码的，它无疑将给我们带来巨大的发展和维护压力。
?1.2、要素分析
?从当前登录用户的角度来看，数据权限的定义可以理解为：当前登录用户只能看到用户权限范围内的数据资源。由此，可以分析数据权限控制的几个关键要素：
?主体，即当前登录用户。领导和角色等概念可以转换为当前登录用户是否是领导者，以及他或她是否具有角色。
?数据资源。即受控系统数据。
?有条件的规则。也就是说，当前登录用户对于特定的数据资源适用的条件。
?2、数据权限设计
?理论上，当用户访问被控制的系统数据时，可以得到用户应用于数据资源的条件规则，并将条件规则解析为SQL查询语句，实现对数据的权限控制。但是，在实现中仍然存在许多困难，例如以下规则适用于当前登录用户：
?客户数据：[客户经理][包含在][下属人员]产品数据：[销售地区][等于][上海]订单数据：（[产品销售地区][等于][上海]）[和]（[客户营销经理][包含在][下属人员]）
?思考如下问题：
?[accountManager][included][submiters]如何解析为SQL语句？如何处理多表联合查询？
?下属由系统根据当前的登录用户进行计算，上海则根据管理员的背景进行选择。这两种方法如何兼容？
?如何设计复杂多变的组合条件？
?如何确定应用于当前查询的条件？
?一个用户应该如何具有多个角色，不同角色应该如何为同一规则设置不同的值？
?2.1、规则元
?名词定义：正则元素。在本文中，它是指一个独立的数据规则定义。不同的用户可以为规则元素设置特定的规则筛选值，作为数据查询的筛选条件。在上述规则中，[客户经理]和[销售地区]属于规则元素。
?2.2、规则元配置
?一。规则元名称的配置。表中的哪些字段可以由规则设置，以及规则元名称如何与表字段相关联。（例如，在上面的规则[客户经理]，[销售区域]）中，很容易想到通过配置文件来维护规则名和数据库字段之间的关系。
?2.规则元素值数据源的配置。例如，【下属人员】和【上海】在上述规则中，不难发现规则人民币价值有三个来源：
?后台管理人员输入。
?系统提供数据源，后台管理器选择。例如：地点[上海]
?系统提供数据。如：[下属人员]
?配置文件可以满足数据规则的配置要求，但是当规则元素越来越多，维护配置文件变得很麻烦，我们可以遵循Spring-boot而不是Spring-MVC的实践，而是使用注释而不是配置？每一条数据规则最终都会落入数据库字段的控制之中，现在大多数系统都会有一个对应于数据库中表的模型层，所以brain组成了一个完美的规则元配置模式：
?@TableName（“test“）
?Public class TestModal extension abstract model {\ expndtw-1
?@数据规则（name=“rule meta name”）
?Private string name;
?}
?@DataRule注解源码如下：
?@Target（{ElementType.FIELD}）
?@Retention (retention policy.(runtime)
?public @interface DataRule {
?/**
?* 规则元名称
?*/
?String name() default ";
?/**
?* 规则元值来源类型
?*/
?RuleSourceStrategy () default RuleSourceStrategy.Text;
?/**
?*当用户选择数据源时{@code rulesourcestrategyChoice}数据地址
?*/
?The string URL () defaults to "";
?/**
?*当数据源由系统提供时{@code rulesourcestrategySystem}提供程序类名称
?*/
?Class provider（） default NullDataRuleProvider.Class;
?}
?启动系统时，规则元素配置信息（名称、对应数据表、对应字段、值源类型、值源URL、值源提供程序类名称等）。)与数据库同步。数据表的简单设计如下：

?

?2.3、数据规则的配置
?使用规则元素信息，管理员可以为系统中的不同用户(角色)设置规则元素值，这是数据查询时的筛选条件。规则元值数据源包括三种情况：情况①和情况②，管理员需要填写或选择规则值，并将其存储在数据库中；情况③，根据当前登录用户计算值，即提供者在@data rule注解中计算的值。数据库存储的规则与系统计算的规则相结合，即登录用户的所有数据规则。
?一个简单的配置界面如下：

? 2.4 数据规则的解析
?如上文所示，当前登录用户的数据规则有两个主要来源：
? 1. 存储在数据库中的规则配置；例如位置[上海]
? 2.需要系统计算的规则配置；如：[下属人员]
? 3.合并两种情况下获得的数据规则后，可获得适用于当前登录用户的数据规则集，流程图如下：

?在这两种情况下获得的数据规则如何兼容？如何将规则组合成复杂的查询条件？
?定义通用的规则结构如下：
?{
?rule:[{
?field: “name“,
?operate: “equal“,
?value: “xxx“
?}],
?operate:“and“,
?group:[{
?rule:[],
?operate:“greater“,
?group:[]
?}]
?}
?数据库存储规则结构的JSON字符串。合并时，反序列化JSON字符串，并使用和连接由系统计算的规则对象。将合并的规则结构解析为一个简单的SQL语句并不困难。
?但是如何处理多表联合查询呢？
?在解析成SQL语句时，可以使用表名+字段名的方法。但是，当在查询中使用别名时，此方法无法正常工作。这里的临时处理方法是支持在解析期间传递别名。
?一个用户应该如何具有多个角色，不同角色应该如何为同一规则设置不同的值？
?例如，用户a具有角色role1和role2，其中：
?ROLE1应用程序规则:[销售区域][等][上海]ROLE2应用程序规则:[销售区域][等][北京]
?那么用户A合并后的数据规则应该是：
?用户a的适用规则：（[销售地区][等于][上海]）或（[销售地区][等于][北京]）
?即：一个用户对于同一个规则元素的多个规则设置，应先使用或连接后再与其他规则元素和连接..
?2.5、确定当前查询适用的数据规则
?通过以上规则的配置和分析，可以方便地得到适用于当前用户的数据规则集。但是我们应该在收集中使用哪些规则来过滤查询？是否在查询中启用数据规则筛选以及使用规则筛选的表应由开发人员决定，类似于：
?XXXQuery(..）.withDataRule（“`table1`，`table2`”）；
?也就是说，表1和表2中配置的数据规则用于当前用户的当前查询。数据表中的每个规则都应该支持是否在管理后台启用，这样理论上每个用户都可以配置每个数据规则。