概述

在之前的博客《数据权限的设计与思考》中，我们对软件系统的数据权限进行了全面的梳理。
接下来，本文深度剖析主流开源的若依开发平台数据权限是怎么设计与实现的。

平台展示

在角色管理菜单中，在角色列表中选择一个具体角色，如平台自带的“普通角色”，然后点击行按钮上的数据权限，如下图所示：

弹出数据权限的配置页面，如下图所示：

当选择自定义数据权限时则会动态加载部门树，根据实际需要勾选后保存角色与部门的对应关系。

设计思路

若依开发平台的数据权限设计比较简易，预置了5种数据范围，具体如下：

• 全部数据权限：所有数据，即不做数据权限控制
• 部门数据权限：用户自己本部门的数据
• 部门及以下数据权限：用户自己本部门及子部门的数据
• 自定数据权限：自定义数据权限
• 仅本人数据权限：自己的数据

从数据范围划分可以看出，平台的数据权限维度主要是部门（部门之外，增加了用户维度的仅本人数据）。
数据权限的配置，是通过角色来实现的，即设置某个角色，能查看的数据范围是以上哪种。
其中，自定数据权限是指可以配置角色对应的部门，控制维度依然是部门。
‍

库表设计

接下来，分析下为了实现数据权限的控制，平台中使用到的库表和字段。

角色表sys_role

因为若依平台的数据权限配置的对象是角色，每个角色对应着预置5种数据范围中的1种，因此在角色表中增加一个字段data_scope，
存放该角色对应的数据范围。

‍

角色与部门对应关系表sys_role_dept

对于自定数据权限，需要配置当前角色能访问哪些部门的数据，因此需要一张对应关系表，来保存角色与部门的对应关系。

‍

部门表sys_dept

对于本部门及以下数据，为了方便获取到当前部门的子部门，在系统部门表中增加了祖级列表字段ancestors。

这个字段怎么来辅助获取子部门呢？结合数据来看就清楚了，如下：

比如挂在长沙分公司的用户，要获取子部门，借助ancestors属性，若依平台中使用mysql数据库的find_in_set函数，通过判断包含关系来获取。
这里实际上是相当于在数据维护阶段多做了一点额外处理工作，然后为数据查询阶段提供便利，避免递归或遍历，提升性能。

系统实现

一般情况下，系统中的大部分功能不需要数据权限控制，而仅有一小部分功能需要。
若依开发平台是通过自定义注解+AOP(切面）来实现的，根据当前用户的角色对应的数据范围，动态生成一个用于数据权限控制的sql片段，然后拼接到原本要执行的sql语句尾部后再执行。

数据权限注解@DataScope

/**
 * 数据权限过滤注解
 * 
 * @author ruoyi
 */
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface DataScope
{
    /**
     * 部门表的别名
     */
    public String deptAlias() default "";

    /**
     * 用户表的别名
     */
    public String userAlias() default "";

    /**
     * 权限字符（用于多个角色匹配符合要求的权限）默认根据权限注解@RequiresPermissions获取，多个权限用逗号分隔开来
     */
    public String permission() default "";
}

数据权限过滤最终是需要通过在要执行的sql语句后动态追加条件的，这样就涉及到原sql语句中对部门表和用户表设置的别名，因此使用deptAlias 和 userAlias来指定。
至于权限字符permission属性，这里仅看注释难以确定具体作用是啥，应该怎么来用，先放一放，后面再说。
‍

切面实现DataScopeAspect

先放上源码，对应的若依的版本是v4.7.9，如下：

package com.ruoyi.framework.aspectj;

import java.util.ArrayList;
import java.util.List;
import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;
import org.springframework.stereotype.Component;
import com.ruoyi.common.annotation.DataScope;
import com.ruoyi.common.core.context.PermissionContextHolder;
import com.ruoyi.common.core.domain.BaseEntity;
import com.ruoyi.common.core.domain.entity.SysRole;
import com.ruoyi.common.core.domain.entity.SysUser;
import com.ruoyi.common.core.text.Convert;
import com.ruoyi.common.utils.ShiroUtils;
import com.ruoyi.common.utils.StringUtils;

/**
 * 数据过滤处理
 * 
 * @author ruoyi
 */
@Aspect
@Component
public class DataScopeAspect
{
    /**
     * 全部数据权限
     */
    public static final String DATA_SCOPE_ALL = "1";

    /**
     * 自定数据权限
     */
    public static final String DATA_SCOPE_CUSTOM = "2";

    /**
     * 部门数据权限
     */
    public static final String DATA_SCOPE_DEPT = "3";

    /**
     * 部门及以下数据权限
     */
    public static final String DATA_SCOPE_DEPT_AND_CHILD = "4";

    /**
     * 仅本人数据权限
     */
    public static final String DATA_SCOPE_SELF = "5";

    /**
     * 数据权限过滤关键字
     */
    public static final String DATA_SCOPE = "dataScope";

    @Before("@annotation(controllerDataScope)")
    public void doBefore(JoinPoint point, DataScope controllerDataScope) throws Throwable
    {
        clearDataScope(point);
        handleDataScope(point, controllerDataScope);
    }

    protected void handleDataScope(final JoinPoint joinPoint, DataScope controllerDataScope)
    {
        // 获取当前的用户
        SysUser currentUser = ShiroUtils.getSysUser();
        if (currentUser != null)
        {
            // 如果是超级管理员，则不过滤数据
            if (!currentUser.isAdmin())
            {
                String permission = StringUtils.defaultIfEmpty(controllerDataScope.permission(), PermissionContextHolder.getContext());
                dataScopeFilter(joinPoint, currentUser, controllerDataScope.deptAlias(),
                        controllerDataScope.userAlias(), permission);
            }
        }
    }

    /**
     * 数据范围过滤
     * 
     * @param joinPoint 切点
     * @param user 用户
     * @param deptAlias 部门别名
     * @param userAlias 用户别名
     * @param permission 权限字符
     */
    public static void dataScopeFilter(JoinPoint joinPoint, SysUser user, String deptAlias, String userAlias, String permission)
    {
        StringBuilder sqlString = new StringBuilder();
        List<String> conditions = new ArrayList<String>();
        List<String> scopeCustomIds = new ArrayList<String>();
        user.getRoles().forEach(role -> {
            if (DATA_SCOPE_CUSTOM.equals(role.getDataScope()) && StringUtils.containsAny(role.getPermissions(), Convert.toStrArray(permission)))
            {
                scopeCustomIds.add(Convert.toStr(role.getRoleId()));
            }
        });

        for (SysRole role : user.getRoles())
        {
            String dataScope = role.getDataScope();
            if (conditions.contains(dataScope))
            {
                continue;
            }
            if (!StringUtils.containsAny(role.getPermissions(), Convert.toStrArray(permission)))
            {
                continue;
            }
            if (DATA_SCOPE_ALL.equals(dataScope))
            {
                sqlString = new StringBuilder();
                conditions.add(dataScope);
                break;
            }
            else if (DATA_SCOPE_CUSTOM.equals(dataScope))
            {
                if (scopeCustomIds.size() > 1)
                {
                    // 多个自定数据权限使用in查询，避免多次拼接。
                    sqlString.append(StringUtils.format(" OR {}.dept_id IN ( SELECT dept_id FROM sys_role_dept WHERE role_id in ({}) ) ", deptAlias, String.join(",", scopeCustomIds)));
                }
                else
                {
                    sqlString.append(StringUtils.format(" OR {}.dept_id IN ( SELECT dept_id FROM sys_role_dept WHERE role_id = {} ) ", deptAlias, role.getRoleId()));
                }
            }
            else if (DATA_SCOPE_DEPT.equals(dataScope))
            {
                sqlString.append(StringUtils.format(" OR {}.dept_id = {} ", deptAlias, user.getDeptId()));
            }
            else if (DATA_SCOPE_DEPT_AND_CHILD.equals(dataScope))
            {
                sqlString.append(StringUtils.format(" OR {}.dept_id IN ( SELECT dept_id FROM sys_dept WHERE dept_id = {} or find_in_set( {} , ancestors ) )", deptAlias, user.getDeptId(), user.getDeptId()));
            }
            else if (DATA_SCOPE_SELF.equals(dataScope))
            {
                if (StringUtils.isNotBlank(userAlias))
                {
                    sqlString.append(StringUtils.format(" OR {}.user_id = {} ", userAlias, user.getUserId()));
                }
                else
                {
                    // 数据权限为仅本人且没有userAlias别名不查询任何数据
                    sqlString.append(StringUtils.format(" OR {}.dept_id = 0 ", deptAlias));
                }
            }
            conditions.add(dataScope);
        }

        // 角色都不包含传递过来的权限字符，这个时候sqlString也会为空，所以要限制一下,不查询任何数据
        if (StringUtils.isEmpty(conditions))
        {
            sqlString.append(StringUtils.format(" OR {}.dept_id = 0 ", deptAlias));
        }

        if (StringUtils.isNotBlank(sqlString.toString()))
        {
            Object params = joinPoint.getArgs()[0];
            if (StringUtils.isNotNull(params) && params instanceof BaseEntity)
            {
                BaseEntity baseEntity = (BaseEntity) params;
                baseEntity.getParams().put(DATA_SCOPE, " AND (" + sqlString.substring(4) + ")");
            }
        }
    }

    /**
     * 拼接权限sql前先清空params.dataScope参数防止注入
     */
    private void clearDataScope(final JoinPoint joinPoint)
    {
        Object params = joinPoint.getArgs()[0];
        if (StringUtils.isNotNull(params) && params instanceof BaseEntity)
        {
            BaseEntity baseEntity = (BaseEntity) params;
            baseEntity.getParams().put(DATA_SCOPE, "");
        }
    }
}

这个类的注释不多，要读懂这段代码，得先了解几个前提：

1. 业务实体类需要有个名称为params的属性，类型是map，里面定义了一个键为“dataScope"的对象，用于存放数据权限控制追加的sql语句。在若依框架中，该属性在基类BaseEntity中定义，业务实体类通过继承基类来拥有了该属性。
2. @DataScope需要标记在服务层方法上，且要求该方法的第一个参数，必须是业务实体对象。
3. 在Mybatis的mapper.xml中，需要在对应的sql语句结尾添加${params.dataScope}

‍
在了解了上面几个前提后，接下来具体说说具体处理逻辑。
首先，通过@Before注解结合切点表达式@annotation(controllerDataScope)，声明在添加了@DataScope注解标记的方法之前，要先执行doBefore方法，如下：

@Before("@annotation(controllerDataScope)")
public void doBefore(JoinPoint point, DataScope controllerDataScope) throws Throwable
{
   clearDataScope(point);
   handleDataScope(point, controllerDataScope);
}

该方法先清空params.dataScope参数，因为该参数可以由前端传入，不处理的话，会成为sql注入的攻击点。
然后调用具体的处理方法handleDataScope。

 protected void handleDataScope(final JoinPoint joinPoint, DataScope controllerDataScope)
    {
        // 获取当前的用户
        SysUser currentUser = ShiroUtils.getSysUser();
        if (currentUser != null)
        {
            // 如果是超级管理员，则不过滤数据
            if (!currentUser.isAdmin())
            {
                String permission = StringUtils.defaultIfEmpty(controllerDataScope.permission(), PermissionContextHolder.getContext());
                dataScopeFilter(joinPoint, currentUser, controllerDataScope.deptAlias(),
                        controllerDataScope.userAlias(), permission);
            }
        }
    }

该方法主要功能实际就是获取当前用户，然后整理数据后调用核心方法——数据范围过滤dataScopeFilter。
‍
dataScopeFilter方法是生成数据权限控制拼接sql的核心方法，主要逻辑如下：

1. 如果角色的数据范围是全部，则重置sqlString为空，并结束循环，即如果遇到当前用户拥有的某个角色，对应的数据范围是全部，意味着无需进行数据权限的过滤，前面可能生成的片段要清理掉，后面的角色也没必要再处理。
2. 如果角色的数据范围是自定义，查询角色与部门对应关系表，生成拼接SQL。
3. 如果角色的数据范围是部门，则将当前用户的部门ID拼接到SQL中。
4. 如果角色的数据范围是部门及子部门，则将当前用户的部门ID和下属部门ID拼接到SQL中。
5. 如果角色的数据范围是仅本人，则判断是否有用户表的别名，若有，则将当前用户的ID拼接到SQL中；若没有，则将部门ID设置为0，表示不查询任何数据。
6. 如果角色都不包含传递进来的权限字符，则将部门ID设置为0，表示不查询任何数据。
7. 最后，如果sqlString不为空，则将拼接好的SQL查询条件设置到方法参数中的第一个对象的params对象dataScope键中。

实际上，就是针对预定义的5种数据范围，来动态生成追加的sql片段。
‍
‍
结合代码，再来看看@DataScope注解中属性permission的有什么用。
这个属性是用于传入权限标识符，类似system:user:list这种形式，这实际是唯一性标识某个功能权限（功能菜单或功能按钮）。
一个用于控制功能权限的标识符，为什么会出现在数据权限的逻辑处理中呢？又能起到什么作用呢？
这块无论是官方的说明文档，还是代码，都没有给出说明和示例。
我们分析下代码，在数据权限过滤方法dataScopeFilter中，会判断角色拥有的权限列表中，是否包含该值，若不包含，说明该角色没相应的权限，直接跳过，这样就意味着对数据权限控制范围的细化。
‍
如果还不理解，再结合一个具体例子来说明。
正因为若依开发平台的数据权限控制不是给各业务实体配置访问规则，而是与角色绑定在一块的，这样就存在一个问题。如果不同的业务功能需要不同的控制范围，只能通过建多个角色来区分。
例如系统有两个业务功能，新闻和通知公告，新闻功能的数据权限控制需求是部门及下级，通知公告的数据权限控制需求是本部门，这样就需要两个角色。但只有两个角色还不够，因为当有人需要新闻和通知公告这两个功能时，就会同时分配两个角色。数据权限处理时是对当前用户拥有的所有角色分别处理，然后取合集，从而就造成一个结果——权限扩大。明明通知公告的需求只是本部门，结果受到新闻功能的数据权限角色影响，下级部门也能查看通知公告了。
而@DataScope注解中属性permission，就是为了区分不同业务功能的数据权限而设立的。
但是这种区分仍有很大的局限性，需要角色“专用”。还是上面这个例子，假设新建了两个角色，需要为这两个角色分别单独授予新闻和通知公告的功能权限，如果任一角色同时授予了新闻和通知公告的功能权限，那么上面说的权限扩大问题依然存在。
‍
因此，要规避权限扩大的问题，客观上就需要新建大量的专用角色出来，造成一定程度上角色“爆炸”问题，并且还需要做好角色规划，在系统运维过程中维护权限时注意不要产生冲突。
‍

总结与回顾

上面我们深入地剖析了若依开发平台对于数据权限控制方面的设计与实现。
平台设计与实现比较简易，控制维度是部门，控制点放在了角色上，内置了5种常见的数据范围。
这种方式存在较大的局限性，一方面，上面分析过程中明确提到的，为了避免权限扩大，需要通过多建角色来处理不同的业务功能数据权限范围需求不同的问题，进而容易造成“角色爆炸”问题；另一方面，实现方案对业务代码属于高侵入，主要体现在以下几点：

1. 要求业务实体类必须具备params属性
2. mapper配置文件中的相关sql语句，必须添加${params.dataScope}占位
3. 业务实体类中部门字段必须为dept_id,用户字段必须为user_id，平台只提供了表别名，字段没有地方设置，算是硬编码了。
4. 权限注解标记的方法，第一个参数必须为实体对象，且继承于BaseEntity，也是硬编码。

‍
综上，若依开发平台的数据权限控制一定程度上解决了简单的数据权限控制问题，但存在较大的局限性。
‍
进一步思考，如果在现有基础上扩展来增加新的控制维度，例如按照项目组，虽然可以实现，但是角色爆炸和业务代码高浸入问题依然存在并会进一步恶化。
‍
‍

开源平台资料

平台名称：一二三开发平台
简介： 企业级通用开发平台
设计资料：csdn专栏](https://blog.csdn.net/seawaving/category_12230971.html)
开源地址：Gitee](https://gitee.com/popsoft/abc-development-platform))
开源协议：MIT
如果您在阅读本文时获得了帮助或受到了启发，希望您能够喜欢并收藏这篇文章，为它点赞~
请在评论区与我分享您的想法和心得，一起交流学习，不断进步，遇见更加优秀的自己！
‍
‍
‍