精华内容
下载资源
问答
  • 数据权限设计研究-行数据权限

    万次阅读 2019-01-17 19:22:56
    数据权限设计研究-行数据权限关于权限设计功能权限数据权限前提数据分类几种场景设计方案与思路映射表提供过滤sql的方法测试实际应用查询新增修改删除修改数据的私有,公开,部门属性私有改为部门私有改为公开部门改...

    关于权限设计

    一般来说,权限模块对于每一个系统而言都是最基础的模块,根据项目需求和功能的不同,设计方案也有许多。但从大的方面来说,可以将权限分为两大类型:功能权限数据权限

    功能权限

    主要控制不同的资源主体(用户、角色、组织等)有操作不同的资源的权限。比如常见的不同的角色能访问不同的页面(菜单权限),以及具有操作同一页面的不同功能(按钮权限)等等。对于java开发而言,功能权限的开发相对来说要简单很多,有很多现成的框架可以实现。我推荐用shiro,因为简单易用,而且能实现按钮级别的控制。

    数据权限

    主要控制不同的资源主体(用户、角色、组织等)有查看不同的数据信息的权限。数据权限又分为数据行权限和数据列权限,本篇文章主要研究一下数据行权限的控制。

    前提

    数据权限一般和业务的关系非常紧密,可能不同的业务有不同的设计方案,所以很难有一种统一而使用简单的设计方案。我的想法是:基于角色-部门的控制方式。即拥有某个角色的人,能看见当前角色所包含的部门中的数据。为了更好的设计数据权限,我总结了一下几种数据。

    数据分类

    1. 公开数据:字面意思,就是公开的数据,不需要控制数据权限。
    2. 部门数据:属于某个部门的数据,只有部门的人员可以查看。
    3. 私有数据:用户自己的数据,只能自己查看。

    几种场景

    1. 某条数据属于多个部门的情况。
    2. 某领导可以跨部门查看数据。
    3. 可以查看子部门的数据。
    4. 私有数据可以分享给别人,部门,或者公开。

    设计方案与思路

    百度上一堆关于数据权限的设计方案,基本上都是基于用户-角色-部门这个来设计,我的思路也和这个差不多,用户与数据角色挂钩,数据角色与部门挂钩,这就比直接角色与部门挂钩要相对灵活一些。虽然某个用户只能属于一个部门,但是有可能出现上面提到的第2中场景,跨部门的情况。
    在这里插入图片描述
    我的设计思路是提供一个方法,写业务的人员需要将查询的表名传给这个方法,然后我返回一段sql,这段sql只是在原来的表上进行数据权限过滤,返回的数据字段和原表一模一样,然后业务代码编写者再把这个sql作为参数传递到DAO层,拼接到FROM后面或者JOIN后面即可。这样无论是单表查询还是多表查询,都可以实现数据权限控制。
    还有一种思路是就是用mybatis拦截器去拦截sql,然后对sql进行改造拼接,但是这样我需要去拦截每一条select的sql,可能会对性能有影响。
    为了少改原有的业务表,同时统一对系统中的表进行数据权限控制,我设计了一张映射表,来映射数据表,部门,用户之间的关系。

    映射表

    映射表字段如下

    字段名 类型 描述 备注
    ID 字符串 主键
    T_ID 字符串 数据表中的主键
    TABLE_NAME 字符串 数据表表名
    D_ID 字符串 部门ID主键
    U_ID 字符串 用户ID主键

    主键字段为字符串纯属个人习惯。
    有了这张映射表,我们就能根据映射表中的部门ID和用户ID是否为空来进行数据权限的识别,同时也能修改数据的所属权限(公开,部门,私有)。

    数据类型 部门ID 用户ID 备注
    公开数据
    部门数据 非空 非空
    私有数据 非空

    因为有私有数据分享给其他人或者部门,单条数据属于多个部门的情况,所以数据表与映射表应该是一对多的关系。

    提供过滤sql的方法

    代码如下

    /**
     * 数据权限sql拼接
     * 
     * @author chunhui.tan
     * @创建时间 2019年1月9日 下午4:30:09
     *
     */
    @Component
    public class DataSqlFilter {
    
    	@Autowired
    	private TsysUserRoleService tsysUserRoleService;
    
    	@Autowired
    	private TsysRoleDeptService tsysRoleDeptService;
    
    	@Autowired
    	private TsysDeptService tsysDeptService;
    
    	/**
    	 * 部门与数据表映射表的表名
    	 */
    	public final String MAPPING_TABLE = "DATA_MAPPING";
    
    	/**
    	 * 
    	 * @param tableName 表名
    	 * @param pkNmae    主键名
    	 * @param isPrivate 是否只获取私有
    	 * @param subDept   是否拥有子部门数据权限
    	 * @return
    	 */
    	public String getDataSql(String tableName, String pkNmae, Boolean isPrivate, Boolean subDept) {
    		// 校验参数
    		checkParam(tableName, pkNmae, isPrivate, subDept);
    		// 判断当前表是否开启数据权限
    		if (!isNeedPermissions(tableName)) {
    			return null;
    		}
    		// 获取当前用户
    		TsysUserEntity user = ShiroUtils.getUserEntity();
    		// 获取部门数据所需要的sql
    		String deptSql = getFilterSql(user, subDept);
    		StringBuilder dataSql = new StringBuilder();
    		dataSql.append("( SELECT DISTINCT S.* FROM ").append(tableName).append(" S LEFT JOIN ").append(MAPPING_TABLE)
    				.append(" T ON S.").append(pkNmae).append(" = T.T_ID AND T.TABLE_NAME= ").append("'").append(tableName)
    				.append("'");
    
    		if (isPrivate) {
    			// 只获取私有数据
    			dataSql.append(" WHERE (T.U_ID = ").append("'").append(user.getEmId()).append("'")
    					.append(" AND (T.D_ID='' OR T.D_ID IS NULL))");
    		} else {
    			// 正常数据:私有数据+部门数据+公开数据
    			dataSql.append(" WHERE T.D_ID IN ").append(deptSql).append(" OR (T.U_ID = ").append("'")
    					.append(user.getEmId()).append("'").append(" AND (T.D_ID='' OR T.D_ID IS NULL))")
    					.append(" OR ((T.D_ID='' OR T.D_ID IS NULL) AND (T.U_ID='' OR T.U_ID IS NULL))");
    		}
    		dataSql.append(")");
    		return dataSql.toString();
    
    	}
    
    	/**
    	 * 判断当前表是否开启数据权限
    	 * 
    	 * @param tableName
    	 * @return
    	 */
    	private Boolean isNeedPermissions(String tableName) {
    		// TODO 这里可以通过表名查询配置或者表来判断改表是否开启了数据权限
    		return true;
    	}
    
    	/**
    	 * 获取部门数据情况下的过滤条件SQL
    	 * 
    	 * @param user
    	 * @param subDept
    	 */
    	private String getFilterSql(TsysUserEntity user, Boolean subDept) {
    		// 部门ID列表
    		Set<String> deptIdList = new HashSet<>();
    		// 用户角色对应的部门ID列表
    		List<String> roleIdList = tsysUserRoleService.queryRoleIdList(user.getEmId());
    		if (roleIdList.size() > 0) {
    			List<String> userDeptIdList = tsysRoleDeptService
    					.queryDeptIdList(roleIdList.toArray(new String[roleIdList.size()]));
    			deptIdList.addAll(userDeptIdList);
    		}
    		// 用户子部门ID列表
    		if (subDept) {
    			List<String> subDeptIdList = tsysDeptService.getSubDeptIdList(user.getEmDeptId());
    			deptIdList.addAll(subDeptIdList);
    		}
    		List<String> result = deptIdList.stream().map(i -> {
    			return "'" + i + "'";
    		}).collect(Collectors.toList());
    		StringBuilder sqlFilter = new StringBuilder();
    		sqlFilter.append("(").append(StringUtils.join(result, ",")).append(")");
    		return sqlFilter.toString();
    	}
    
    	/**
    	 * 参数校验
    	 * 
    	 * @param tableName
    	 * @param pkNmae
    	 * @param isPrivate
    	 * @param subDept
    	 */
    	private void checkParam(String tableName, String pkNmae, Boolean isPrivate, Boolean subDept) {
    	//TODO 进行sql注入的校验
    		if (StringUtils.isBlank(tableName) || StringUtils.isBlank(pkNmae) || null == isPrivate || null == subDept) {
    			throw new XcrmsException("数据权限-缺少参数");
    		}
    	}
    }
    
    

    测试

    当前系统使用shiro做的权限,角色分成两种类型,一种是功能角色,一种是数据角色。功能角色与菜单按钮挂钩,数据角色与部门挂钩。接下来用PostMan接口测试方式来测试获取到的sql。

    只获取私有数据

    @Autowired(required = true)
    private DataSqlFilter dataSqlFilter;
    
    	/**
    	 * test
    	 * 
    	 * @param id
    	 * @return
    	 */
    	@GetMapping("/getDataSql")
    	public Result getDataSql() {
    		String dataSql = dataSqlFilter.getDataSql("PRODUCT", "P_ID", Boolean.TRUE, Boolean.FALSE);
    		System.out.println(dataSql);
    		return ResultUtil.success(dataSql);
    	}
    

    结果用Navicat处理一下:
    在这里插入图片描述
    获取普通数据
    所谓普通数据就是用户正常能看见的数据:私有数据+部门数据+公开数据。
    将参数isPrivate设置为false即可

    @Autowired(required = true)
    	private DataSqlFilter dataSqlFilter;
    
    	/**
    	 * test
    	 * 
    	 * @param id
    	 * @return
    	 */
    	@GetMapping("/getDataSql")
    	public Result getDataSql() {
    		String dataSql = dataSqlFilter.getDataSql("PRODUCT", "P_ID", Boolean.FALSE, Boolean.FALSE);
    		System.out.println(dataSql);
    		return ResultUtil.success(dataSql);
    	}
    
    

    结果用Navicat处理一下:
    在这里插入图片描述

    实际应用

    查询

    业务开发人员在查询是只需要调用这个方法获取到sql后,然后作为参数传入DAO层,在mybatis的xml文件中拼接即可(图片中的${dataSql}应为#{dataSql}),如下:
    在这里插入图片描述

    新增

    新增业务数据时,业务需要知道这个数据时那种数据类型,然后新增数据后,需要新增一条映射记录。提供过滤sql的类中可以提供统一的新增映射数据的方法。还没写,大概如下:

    	/**
    	 * 新增映射数据
    	 * 
    	 * @param pk_value  数据表数据主键值
    	 * @param tableName 数据表表名
    	 * @param type      数据类型 0 私有 1 公开 2 部门
    	 */
    	public void addMapping(String pk_value, String tableName, Integer type) {
    		// TODO 可以通过shiro获取到当前登录的用户,然后获取到用户的部门,然后根据type来新增映射关系
    
    	}
    
    

    修改

    若只是修改数据,则不关映射表的事。

    删除

    删除时需要注意,因为某条数据可能属于多个部门或者多个个人,那么当删除掉这条数据后,那么映射表中就存在多条T_ID相同和TABLE_NAME相同的数据,删除的时候应该通过T_ID和TABLE_NAME来删除映射表中的所有数据。

    修改数据的私有,公开,部门属性

    即修改映射表,按道理说,一般只会存在数据的所有人能修改,但是以防万一,业务开发人员需要判断当前数据的U_ID是否与当前用户的用户ID一致,不一致不能修改。当然,公开数据时不需要进行这一步校验的。以下修改方法都可以在DataSqlFilter类中统一提供

    私有改为部门

    即用户将私有数据分享给指定的部门
    修改方式:修改映射表中的D_ID为用户指定的部门ID

    私有改为公开

    即用户将私有数据全部公开
    修改方式:置空映射表中的U_ID和D_ID

    部门改为公开

    即将部门所拥有的数据公开
    修改方式:置空映射表中的U_ID和D_ID

    其他变更

    其他变更只要对照上面那张数据类型表即可进行修改。

    总结

    有人可能会说为什么不在原来的业务表上面加上部门ID和用户ID,从而不用映射表?
    但是这样会有一些问题,一是实际开发过程中,往往由于需求的变化,很难确定哪些表需要加部门ID和用户ID。二是这样无法满足一些特殊需求,比如:个人数据分享出去给其他人或者部门,单条数据属于多个部门。
    总结下来用以上方案来控制数据权限的优缺点如下
    优点:
    1.统一提供过滤sql,维护映射表,修改数据类型的方法,而且不用修改业务数据表,对原来的代码入侵最小化。
    2.不论是单表查询还是多表都能支持。
    3.比较灵活,针对不同需求,可以灵活调整过滤sql

    缺点:
    1.因为在对原表进行过滤时需要连接映射表,假如是多表联查,每张表都要连接映射表,可能对查询性能有影响。
    2.因为每条业务数据都会对应一条映射数据,那么意味着映射表将会有很多数据,在过滤的时候会影响性能,当然这里可以用分模块设计多个映射表的方法来解决。

    以上只是一个设计思路,还没用于实际项目,如有不足,欢迎斧正,谢谢。

    展开全文
  • 从零开始java数据权限篇:数据权限

    千次阅读 2019-09-09 11:59:05
    一:数据权限的产生 二:数据权限的数据切割 1.数据对应的层级图 2.用户数据查询 3.用户流程管理 4.部门-岗位-公司查询拓扑图 三.说明 一:数据权限的产生 在一个后管系统中,由2个最重要的权限划分。第一...

    目录

    一:数据权限的产生

    二:数据权限的数据切割

    1.数据对应的层级图

    2.用户数据查询

    3.用户流程管理

    4.部门-岗位-公司查询拓扑图

    三.说明



    一:数据权限的产生

      在一个后管系统中,由2个最重要的权限划分。第一个访问权限,通过控制访问路径、请求来控制访问的权限,第二个是数据权限,通过一系列的分割策略来对用户进行管理。

     访问权限,可以这么说访问权限可以通过集成框架(比如shiro或者Spring seurity或者oauth2)来控制。所以严格意义上来说访问权限是一个技术框架

     数据权限,数据权限用来对用户信息进行管理包括但是不限于用户列表查询、子母公司数据划分以及工作流等的一系列。但是一个比较尴尬的问题就是,数据权限实则是一个业务层,它是由具体的公司业务来决定的。当然,凡是可以抽象出来的我们都可以抽象出来。目前主流的的数据权限控制以 部门-岗位-上级-本级 这样一个递减结构来做通用式的管理。

      也翻看了一些所谓的数据级权限中间件比如目前介绍较多的Ralasafe,实则上就是在访问Sql上做一些侵入式Sql限制。基于此,我们完全可以在项目中使用AOP做。但是很尴尬的是目前这个数据级的中间件已经停止维护。

     

    二:数据权限的数据切割

      在上面,我们谈到一般都是以 部门-岗位-上级-本级 的结构来做数据权限控制。但是一般项目中会把上级-本级合并产生一个简单的结构:部门-岗位-用户 来维护数据权限。

    1.数据对应的层级图

                                                   

      首先:部门对于用户而言,是用户固有的一个属性,只能是一对一关系。

                  岗位对于用户而言 ,是由上级或者管理员分配的一个属性,可以是一对多(即一个用户被指向多个部门的负责人,但是

                                                        他本身只有某一个部门的属性)。

                  部门对岗位而言,同时也是一对多的关系,即一个部门有多个角色。

    2.用户数据查询

                   

     然后,我们针对组织结构细分:

     (1)公司结构以及部门结构:管理层级(具有本部门的最高权限)以及一般员工(只有自我查询权限)

                                                           其中总公司的管理层具有整个结构的最高权限。

    (2)单个单位中的结构:单个单位内的负责人具有最高单位权限

                                                  单个单位的次级负责人具有管理名下的权限。(即上级-下级的管理权限)

                                                   单个单位内的普通员工只具有自身的权限

    3.用户流程管理

      由于后期要整合工作流,因此这里我们将流程梳理清晰。

     

    4.部门-岗位-公司查询拓扑图

    目前,主要角色分为以下几个:

    (1)普通员工(仅能看到自己的信息)

    (2)部门管理人(仅能看到本部门)

    (3)分公司董事(除了董事会部门的其他分公司所有的部门)

    (4)分公司总负责人(看到分公司所有的信息)

    (5)总公司董事会(除了总公司董事会之外的所有总,自公司的所有部门)

    (6)总董事

    部门-岗位-董事表拓扑(比较简单,就不做UML了)

    据图查询:

    (1)普通员工:这个就不用说了

    (2)部门负责人:查询 用户表中 部门id一样的即可

    (3)分公司董事会:第一步,根据用户表中的部门id去查询部门表

                                          第二步:根据部门表中的所有上级id,取出公司统一的开头(一般第一位为总公司id,第二位为

                                                          分公司id,第三位包括以后是部门层级一级一级玩下的id,以逗号隔开)

                                         第三步:根据公司统一的开头曲模糊查询所有的部门id(这里在程序中控制得当,是完全可以的)

                                         第四步:根据上一步的部门id,同时去掉本身的部门id(即董事会部门的id),然后反查用户表

     (4)分公司负责人 :在上一个的第四步,不去掉本身的部门id

     (5)总公司董事会:查询所有的,除了自身的部门id

    (6)总公司负责人:全查

    (7)自定义:选择部门,然后插入  岗位-部门表做联查(对,这个表只在这里用到)

    三.说明

      上面所描述的是通常情况下,一般都是根据具体业务做管理

     

     

    展开全文
  • 数据权限系统

    万次阅读 2018-04-08 12:44:45
    在之前写过一篇关于菜单权限系统的设计,所以为了完善整个权限系统的模型,决定把数据权限也做一个总结。菜单权限管理系统目标实现对数据的权限控制。简单的来说,就是决定谁可以操作(增删改查)哪些数据。该权限...

    在之前写过一篇关于菜单权限系统的设计,所以为了完善整个权限系统的模型,决定把数据权限也做一个总结。菜单权限管理系统

    目标

    实现对数据的权限控制。简单的来说,就是决定谁可以操作(增删改查)哪些数据。

    该权限模型的适用范围

    该模型目前在一些常用的管理平台得到的验证与实施,目前已应用在多个公司产品中,主要场景是CRM类项目。

    核心难点

    数据权限的主要难度在于查询的性能、授权、鉴权,字段级别的控制。

    比如在百万级别规模时,mysql如何实现秒级别的查询?

    场景介绍:在之前设计该权限模型时,我们的项目遇到了一个核心的难题,sql的查询速度非常的缓慢!!!一个sql可能高达10S+。这对于用户而言,是无法接受的。所以我们尝试去优化sql的表设计,索引的优化,但是最终结果都摆阵下来。主要的问题是我们并没有足够抽象数据,导致百万级别的数据下,sql非常缓慢。这里面占时不需要考虑分库分表(百万级别的规模不足以使用该手段)。

    百万级别的数据权限怎么授予用户?

    场景介绍:面对如此大的数据量,如何授权用户权限呢?总不能是逐个分配的!!!

    如何快速高效的进行数据鉴权呢?

    场景介绍:这么大的数据量,在程序中不容易处理,必须借助于数据库的高效查询方案,但是怎么实现呢?

    如何实现字段级别的权限控制?

    场景介绍:字段级别的权限怎么控制?控制sql的生成逻辑?还是怎么处理呢?

    权限模型的抽象

    有了那么多的问题,我们先从权限模型入手,我们必须高度抽象化我们的权限系统,才有机会做到。

    下面我们直接贴出一个图,介绍该模型的一些核心概念


    我们根据上图所示,可以观察到下面的几个元素,分别是:权限实体部门角色菜单权限

    其中菜单权限参考上面的链接

    权限实体:这个是该权限模型的核心元素,也就是我们需要系统控制的数据。比如客户,订单,渠道,区域等。

    部门:这个简单,就是一般的部门组织结构

    角色:抽象的实体,用于快速分配权限相同权限给一批用户,与菜单权限的角色概念一致。

    权限的查询模型

    在上面的图中,不知道大家是否看到了一条sql

    select xxx from xx_table where account in (xxx) and product_group in (xxx) and country in (xxx)

    没错,这就是该模型的查询模型。其中account,product_group,country代表需要做权限控制的权限实体。

    在这里面只是一个简单的模型,如果account或者country等数据量足够大时,我们会发现mysql in查询是会出现非常严重的查询性能的。比如account数据量规模为100W时...

    引入部门组织结构,突破数据量的限制

    还是看上图,我们有一个部门组织结构,我们可以想象下,比如总经理,自然是可以查看所有部门的数据。假设A部门经理,可以查看A部门以及子部门的数据。如果是普通的员工,只能查看自己账号下的数据。

    下面我们给出一个部门组织结构图,并且给每个部分标志一个key,key的生成规则如下

    1.根部门的key为数字10

    2.根部门的直属部门的key为10 001,10 002,10 003...以此类推

    3.其他的key生成逻辑和步骤2相同,唯一不同的就是key的长度变长了,比如:10 001 001,10 001 002

    这里面我们给部门打上如下的key,为了方便介绍,我们还是贴图片


    有了该模型,我们结合mysql的前置查询索引的特性(org like 'xxxx%')

    where org like '10%'
    org like '10001%'
    org like '10002%'
    上面的查询,在mysql下,200W的数据规模,可以实现1S内响应!!!

    如何授权

    解决了查询的性能,其实授权也就很简单了。

    授权我们一般根据员工的岗位来设定,普通员工,部门经理

    普通员工:不需要单独授权,直接绑定员工工号即可

    部门经理:设置该员工可以查看的部门(支持多个)

    如何鉴权

    鉴权和授权一般是相互的一个过程

    1.判断该员工是否为部门经理

    2.如果是,取出部门的key

    3.添加到sql中,使用mysql前置like查询数据

    字段权限的控制

    字段权限的控制,我们直接针对接口编程,不要针对sql编程。

    比如获取员工列表:我们只需要控制输出的字段属性即可。

    为啥不针对sql编程?因为sql需要考虑各种join,字段是否缺失,关联的内容存储在其他表等情况

    数据库的实现

    1.识别权限实体

    2.给权限实体加上一个工号字段,一个部门字段,比如:emp_id,org_key

    3.查询时,先获取员工的角色权限,如果是部门经理,那么获取对应的key列表

    4.构建sql,加入部门或者工号的sql片段

    • org_key lik '10 001%' or org_key like '10 002%',这是部门的sql
    • emp_id = 'xxx',这是普通员工的sql

    总结

    设计好一个权限系统,说难不难,但是也不简单。

    主要的难点在于

    1.识别出你需要控制的数据(权限实体)

    2.高效的查询效率与sql的索引相结合(这里面使用部门key与sql的前置查询)

    应用于扩展

    该模型设计简单,具备一定的普遍性,所以在设计时,我们可以根据不同的系统去进行演进与扩展。大家有兴趣的可以思考下

    展开全文
  • 功能权限和数据权限

    万次阅读 2017-11-02 11:01:05
    权限分为数据权限和功能权限 1、功能权限:  能不能打开某一个界面,能不能触发一个界面上的一个按钮,某些业务员能不能删除订单,采购员能不能删除业务员某个销售订单,带着一系列问题?这是什么问题。没错这就是...

    在任何系统中都需要权限控制,没有权限,系统是不健全的时刻会受到各种问题的干扰。

    权限分为数据权限和功能权限

    1、功能权限:

           能不能打开某一个界面,能不能触发一个界面上的按钮,某些业务员能不能删除订单,采购员能不能删除业务员某个销售订单,刚入职的小白误入系统管理员的界面,胡乱的修改。这是什么问题?没错这就是功能权限。

          曾今做过两个系统对功能权限的控制

          1)、某某公司ERP系统:

                 业务员具有新增,删除,查看,作废销售订单的权限,其实那家上市公司不允许业务员具有删除,作废导致流水号不连续无法更好的管理订单信息,后来鉴定那样的设计其实是非常不好的:将权限直接赋值给某某人,如:直接将新增的权限赋值给小李,删除权限赋值给小张,作废的权限赋值给小王,后来想给小李作废的权限,然后又重新将作废的权限赋值给小李,后来来了个新员工小芳,小芳想具有小李,小张,小王的权限,咋个办呢?一个系统几百个权限当时的系统管理员不干了,这种权限赋值对他的操作太麻烦了。每增加一个人权限赋值都是一个体力活,特别是某某人想具有某些人的权限,这无疑是增加了系统管理员的工作量。

         2)、某某数据分析系统:

               借鉴了某某公司ERP系统功能权限的失败:在权限和人之间追加了一个角色,先将新增,删除,查看,作废等权限赋值给莫某角色,然后给某某人赋值某某角色,这样某某人就具有某某权限了,某人想拥有某些人的权限,直接将这些人的角色赋值给某人,这样某人就具有某些权限,同时减少了权限赋值给人的难度。

    2、数据权限:

              场景1、 业务员A在业务员B某个订单上查看了某某客户对某某产品的销售单价,在某某搜搜框中搜出其他业务员的订单信息,可以随意的查看其他人的订单信息,其他人的业务员客户信息,其他人负责的产品信息,这无疑不是对系统健全的挑战。

               场景2、 某业务主管看到公司某产品的平均毛利率,某客户的平均毛利率,重则带着下面一群小弟出去创业,称为公司的竞争对手,这无疑会对公司造成损失。

    数据权限无非就是某人只能看到某些数据,这些数据是可能是属于自己直接操作的,也可能是间接操作的。

    模拟ERP系统数据权限,某业务员A想知道自己有哪些客户,于是打开了客户管理界面,看到的客户全是自己相关的,假如没有数据权限的设定 ,会看到有部分不属于自己负责客户。如何统计出某业务主管自己今年销售状况好的产品有那些?曾经碰到两种情况出发:第一种业务主管负责的业务员 ,另外一种直接从负责的客户出发。

            1)、业务主管负责业务员所卖的产品

             业务主管根据自己负责的所有业务员统计出所有负责的产品然后筛选出,现实生活中的可不是那么的理想,某某主管负责的业务员全在自己负责的客户正常工作。如果一个业务员负责的客户时刻在发生变化,并且业务员所负责的客户不属于当前业务主管负责,那么统计出来的数据就会受到质疑,刁难的客户会对软件产生极大的不满。

            2)、业务主管负责客户所买的产品

            直接从客户入手,根据客户统计出主管的销售状况是对业务主管负责业务员变动的补充。

            我是这样理解的访问一个系统必定是根据人出发,以人为切入点,设计好人和人之间的关系,人和部门之间的的关系,人和客户之间的关系,人和产品之间的关系,人和供应商之间的关系。一切从关系出发查找数据,这就是数据权限

      

    展开全文
  • 数据权限方案

    千次阅读 2018-10-16 14:31:19
    数据权限说起来比较简单,但是实际实现过程中,也是非常复杂的,比如,同样是select表,可能是对原样的表名及字段名进行访问,也可以是把表名和字段名取了别名,另外还会涉及到复杂的查询和子查询。 同样的数据列...
  • 权限管理-数据权限

    千次阅读 2016-05-12 11:36:56
    权限管理-数据权限
  • 若依数据权限

    千次阅读 2020-12-06 00:33:45
    若依数据权限是通过使用自定义注解,AOP拦截,实现将数据权限的sql插入Mapper文件中,从而达到控制数据权限的目的。
  • 浅谈权限(功能权限&数据权限

    千次阅读 2020-02-28 11:38:18
    一般企业上的权限部分,都是区分为功能权限和数据权限。 功能权限: 功能权限,就是用户登录后,能看到哪些菜单,能看到哪些按钮,能执行哪些操作的权限。 一般,功能权限,已经都有很成熟的业内方案和框架了。 比如...
  • 数据权限控制

    千次阅读 2018-08-28 10:18:01
    查询参数经过控制层,aop组件对参数进行拦截,读取redis缓存中的数据权限数据,进而对参数进行重新组装。 从新组装的查询参数传递到业务处理层。 业务处理层将查询参数传递到数据访问层。 Sql分析组装组件对查询...
  • 《JeeSite4.x数据权限教程》全课程时长:04:56:49 https://space.bilibili.com/383413957/channel/detail?cid=75515 并额外免费赠送45套全栈工程师视频教程资源地址 赠送教程列表: 免费 《JeeSite4.x数据...
  • ruoyi框架数据权限

    千次阅读 2020-07-14 09:54:54
    ruoyi框架数据权限 1.页面设置对应角色的数据权限 2.service层加上@DataScope注解 部门表的别名deptAlias = “d” 用户表的别名userAlias = “u” 3.sql上加上过滤
  • 通用权限管理设计 之 数据权限

    万次阅读 2018-01-04 10:09:40
    本文将对这种设计思想作进一步的扩展,介绍数据权限的设计方案。 权限控制可以理解,分为这几种 : 【功能权限】:能做什么的问题,如增加产品。 【数据权限】:能看到哪些数据的问题,如查看本人的所有订单。 ...
  • mybatis整合数据权限

    千次阅读 2019-05-18 12:54:42
    现在很多企业级应用都需要拦截数据权限, 只有配置了相应数据权限的人才能看到该数据 关于数据权限的实现, 个人想了两种实现方式 第一种是基于AOP, 配置相应的注解, 在切面中将数据权限的参数值强制设置到请求参数中...
  • 通用数据权限的设计思路

    千次阅读 2020-01-02 09:25:30
    根据目前的调研情况,有两种数据级别权限设计思路,都可以实现对人员访问的数据权限控制,从而实现不同的人员能够看到不同的数据,例如经理能够看到其部门下所有人的数据,而单个的员工只能看到自己的数据。...
  • 浅谈数据权限

    万次阅读 2017-04-23 16:47:25
    数据权限参考
  • CRM-数据权限设计

    2019-07-06 13:48:37
    CRM-数据权限数据权限概念1.数据权限使用方式分类2.数据权限设置支持的权限3.数据权限模型4.数据权限场景描述5.数据权限配置解决方案6.数据权限的功能支持列表6.7数据权限使用规范 数据权限概念 对企业应用的各种...
  • hive数据权限管理

    千次阅读 2017-02-27 14:35:19
    hive数据权限管理:权限说明、开启权限管理、权限配置、超级权限。 hive能对数据文件的权限控制,未能控制元数据权限,考虑引入Apache Sentry组件。
  • 通用数据权限管理系统设计

    千次阅读 2018-03-08 15:33:38
    通用数据权限管理系统设计(一) 作者:逸云 前言: 本文提供一种集成功能权限和数据权限的解决方法,以满足多层次组织中权限管理方面的集中控制。本方法是RBAC(基于角色的访问控制方法)的进一步扩展和延伸,即...
  • 功能权限和数据权限管理的实现

    万次阅读 2018-01-10 11:36:19
    功能权限和数据权限管理的实现 转自 http://blog.csdn.net/xuanbg/article/details/23286717 标签:企业 /权限 1 引言 权限,可分为“功能(操作)权限”和数据权限两种,在系统中,两种...
  • 数据权限设计

    千次阅读 2014-03-02 20:45:46
    数据权限设计思考目前有关用户权限采用的比较多的都是基于RBAC模型 目前有关用户权限采用的比较多的都是基于RBAC模型,即通过对角色权限的定义完成对用户权限的限制。有关功能权限部分想必都比较清楚,就是将系统的...
  • 数据权限设计(转载)

    万次阅读 2019-01-01 13:57:49
    几乎在任何一个系统中,都离不开权限的设计,权限设计 = 功能权限 + 数据权限,而功能权限,在业界常常是基于RBAC(Role-Based Access Control)的一套方案。而数据权限,则根据不同的业务场景,则权限却不尽相同,...
  • 基于SpringAOP实现数据权限控制

    万次阅读 2018-01-05 19:24:14
    基于SpringAOP实现数据权限控制 在此主要是实现对用户查询数据返回字段的控制。比如一个表格有A,B,C,D,E五列,用户U1只能查看A,B,C三列。 此文章讲述的内容并不能实现在查询时仅查询A,B,C三列,而是在查询...
  • 基于若依框架的数据权限

    千次阅读 2020-11-21 20:15:24
    数据权限 数据权限和菜单权限不一样 菜单权限: 根据不同的性质的用户,显示不同的菜单。 数据权限: 设置权限,不同的用户只能访问本用户的数据,或者本部门的数据。当然对于特殊的领导可以跨部门访问数据。这些...
  • JAVA 数据权限设计

    万次阅读 2014-07-17 09:34:18
    在各种系统中,要保证数据对象的安全性以及易操作性,使企业的各业务部门、职能部门能够方便而且高效的协同工作,那么一个好的数据权限管理设计就成为一个关键的问题。虽然企业中各个单元的工作流程有所不同,处理的...
  • 通用数据权限模型

    千次阅读 2013-11-17 15:41:52
    下面模型本人在工作中根据实际情况提出使用的数据权限模型。 1. 问题提出 如何能通用的进行数据权限处理。 2. 主要思路 从数据库角度来看,数据权限的实现最终都是落在用某张表的某个字段取值范围来达到。结合公司...
  • 基于mybatis拦截器实现数据权限

    万次阅读 2018-12-02 11:41:38
    数据权限是很多系统常见的功能,实现的方式也是很多的,最近在做项目的时候,自己基于mybatis拦截器做了一个数据权限的功能。 **功能设计 a) 需要做数据权限功能的表加上一个权限id字段。 权限id可以不仅仅是...
  • 针对不同用户,在数据查询时要在SQL上拼上可以访问的部门机构部分。...这里看到一种比较好的方法可以实现数据权限。 使用方法 其中tableAlias为SQL中表的别名。 @DataAuth(tableAlias = "s") public Result...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 69,471
精华内容 27,788
关键字:

数据权限