数据权限方案设计资料.docxVIP

数据权限方案设计 精品文档 精品文档 收集于网络，如有侵权请联系管理员删除 收集于网络，如有侵权请联系管理员删除 精品文档 收集于网络，如有侵权请联系管理员删除 数据权限方案设计 权限控制主要分为两块，认证（Authentication）与授权（Authorization）。认证之后确认了身份正确，业务系统就会进行授权，现在业界比较流行的模型就是RBAC（Role-Based Access Control）。RBAC包含为下面四个要素：用户、角色、权限、资源。用户是源头，资源是目标，用户绑定至角色，资源与权限关联，最终将角色与权限关联，就形成了比较完整灵活的权限控制模型。 资源是最终需要控制的标的物，但是我们在一个业务系统中要将哪些元素作为待控制的资源呢？我将系统中待控制的资源分为三类： URL访问资源（接口以及网页） 界面元素资源（增删改查导入导出的按钮，重要的业务数据展示与否等） 数据资源 现在业内普遍的实现方案实际上很粗放，就是单纯的“菜单控制”，通过菜单显示与否来达到控制权限的目的。平台分为To C和To B两种： To C一般不会有太多的复杂权限控制，甚至大部分连菜单控制都不用，全部都可以访问。 To B一般都不是开放的，只要做好认证关口，能够进入系统的只有内部员工。大部分企业内部的员工互联网知识有限，而且作为内部员工不敢对系统进行破坏性的尝试。 所以针对现在的情况，考虑成本与产出，大部分设计者也不愿意在权限上进行太多的研发力量。 菜单和界面元素一般都是由前端编码配合存储数据实现，URL访问资源的控制也有一些框架比如SpringSecurity，Shiro。 目前还没有数据权限控制的框架或者方法，所以自己整理了一份。 1、数据权限控制原理 数据权限控制最终的效果是会要求在同一个数据请求方法中，根据不同的权限返回不同的数据集，而且无需并且不能由研发编码控制。这样大家的第一想法应该就是AOP，拦截所有的底层方法，加入过滤条件。这样的方式兼容性较强，但是复杂程度也会更高。我们这套系统中，采用的是利用Mybatis的plugin机制，在底层SQL解析时替换增加过滤条件。 这样一套控制机制存在很明显的优缺点，首先缺点： 适用性有限，基于底层的Mybatis。 方言有限，针对了某种数据库（我们使用Mysql），而且由于需要在底层解析处理条件所以有可能造成不同的数据库不能兼容。当然Redis和NoSQL也无法限制。 当然，假如你现在就用Mybatis，而且数据库使用的是Mysql，这方面就没有太大影响了。 接下来说说优点： 减少了接口数量及接口复杂度。原本针对不同的角色，可能会区分不同的接口或者在接口实现时利用流程控制逻辑来区分不同的条件。有了数据权限控制，代码中只用写基本逻辑，权限过滤由底层机制自动处理。 提高了数据权限控制的灵活性。例如原本只有主管能查本部门下组织架构/订单数据，现在新增助理角色，能够查询本部门下组织架构，不能查询订单。这样的话普通的写法就需要调整逻辑控制，使用数据权限控制的话，直接修改配置就好。 2、数据权限实现 上一节就提及了实现原理，是基于Mybatis的plugins （查看官方文档）实现。 MyBatis 允许你在已映射语句执行过程中的某一点进行拦截调用。默认情况下，MyBatis 允许使用插件来拦截的方法调用包括： Executor (update, query, flushStatements, commit, rollback, getTransaction, close, isClosed) ParameterHandler (getParameterObject, setParameters) ResultSetHandler (handleResultSets, handleOutputParameters) StatementHandler (prepare, parameterize, batch, update, query) Mybatis的插件机制目前比较出名的实现应该就是 PageHelper项目了，在做这个实现的时候也参考了PageHelper项目的实现方式。所以权限控制插件的类命名为PermissionHelper。 机制是依托于Mybatis的plugins机制，实际SQL处理的时候基于jsqlparser这个包。 设计中包含两个类，一个是保存角色与权限的实体类命名为PermissionRule，一个是根据实体变更底层SQL语句的主体方法类PermissionHelper。 数据结构中保存如下几个字段： 角色列表：需要使用此规则的角色，可以多个，使用英文逗号隔开。 实体列表：对应的规则应用的实体（这里指的是表结构中的表名，可能你的实体是驼峰而数据库是蛇形，所以