从开源框架若依的获取用户信息接口发掘角色与权限表设计

发表于 更新于 本文字数： 761 阅读时长 ≈ 3 分钟

1

接口入手

我们发现，若依的getInfo接口获取了用户的roles与permissions以及用户的基本信息，我们来研究一下其获取逻辑与sql，从而尝试从接口与sql研究其权限表设计结构。

getInfo接口

在Controller中，其代码实现为：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
/**
     * 获取用户信息
     * 
     * @return 用户信息
     */
    @GetMapping("getInfo")
    public AjaxResult getInfo()
    {
        SysUser user = SecurityUtils.getLoginUser().getUser();
        // 角色集合
        Set<String> roles = permissionService.getRolePermission(user);
        // 权限集合
        Set<String> permissions = permissionService.getMenuPermission(user);
        AjaxResult ajax = AjaxResult.success();
        ajax.put("user", user);
        ajax.put("roles", roles);
        ajax.put("permissions", permissions);
        return ajax;
    }

我们展开看一下其中的角色集合与权限集合方法。

1
2
3
4
// 角色集合
Set<String> roles = permissionService.getRolePermission(user);
// 权限集合
Set<String> permissions = permissionService.getMenuPermission(user);

getRolePermission

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
/**
     * 获取角色数据权限
     * 
     * @param user 用户信息
     * @return 角色权限信息
     */
    public Set<String> getRolePermission(SysUser user)
    {
        Set<String> roles = new HashSet<String>();
        // 管理员拥有所有权限
        if (user.isAdmin())
        {
            roles.add("admin");
        }
        else
        {
            roles.addAll(roleService.selectRolePermissionByUserId(user.getUserId()));
        }
        return roles;
    }

对于管理员，仅需要添加admin即可，否则则需要按照用户id去查询用户权限，我们再次深入，展开selectRolePermissionByUserId方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
/**
     * 根据用户ID查询权限
     * 
     * @param userId 用户ID
     * @return 权限列表
     */
    @Override
    public Set<String> selectRolePermissionByUserId(Long userId)
    {
        List<SysRole> perms = roleMapper.selectRolePermissionByUserId(userId);
        Set<String> permsSet = new HashSet<>();
        for (SysRole perm : perms)
        {
            if (StringUtils.isNotNull(perm))
            {
                permsSet.addAll(Arrays.asList(perm.getRoleKey().trim().split(",")));
            }
        }
        return permsSet;
    }

方法第一句调用mapper中的方法，实际是执行sql查询，我们看一下其执行的sql：

1
2
3
4
5
6
7
select distinct r.role_id, r.role_name, r.role_key, r.role_sort, r.data_scope, r.menu_check_strictly, r.dept_check_strictly,
            r.status, r.del_flag, r.create_time, r.remark 
        from sys_role r
	        left join sys_user_role ur on ur.role_id = r.role_id
	        left join sys_user u on u.user_id = ur.user_id
	        left join sys_dept d on u.dept_id = d.dept_id
WHERE r.del_flag = '0' and ur.user_id = #{userId}

由此，得到其角色表主表为sys_role，角色与用户关联表为sys_user_role。从表命名上我们也能看出一二来。

getMenuPermission

同样的，我们展开权限方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
/**
    * 获取菜单数据权限
    * 
    * @param user 用户信息
    * @return 菜单权限信息
    */
   public Set<String> getMenuPermission(SysUser user)
   {
       Set<String> perms = new HashSet<String>();
       // 管理员拥有所有权限
       if (user.isAdmin())
       {
           perms.add("*:*:*");
       }
       else
       {
           perms.addAll(menuService.selectMenuPermsByUserId(user.getUserId()));
       }
       return perms;
   }

若是admin，则只添加*:*:*，否则执行方法：selectMenuPermsByUserId，我们再次深入展开：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
/**
     * 根据用户ID查询权限
     * 
     * @param userId 用户ID
     * @return 权限列表
     */
    @Override
    public Set<String> selectMenuPermsByUserId(Long userId)
    {
        List<String> perms = menuMapper.selectMenuPermsByUserId(userId);
        Set<String> permsSet = new HashSet<>();
        for (String perm : perms)
        {
            if (StringUtils.isNotEmpty(perm))
            {
                permsSet.addAll(Arrays.asList(perm.trim().split(",")));
            }
        }
        return permsSet;
    }

同样的，关键语句在于sql查询selectMenuPermsByUserId：

1
2
3
4
5
6
select distinct m.perms
		from sys_menu m
			 left join sys_role_menu rm on m.menu_id = rm.menu_id
			 left join sys_user_role ur on rm.role_id = ur.role_id
			 left join sys_role r on r.role_id = ur.role_id
		where m.status = '0' and r.status = '0' and ur.user_id = #{userId}

我们发现，若依系统中，获取的权限实际上都属于“菜单”的权限，注意，这里的菜单包括实际意义的菜单以及菜单中的按钮，即包括下图两个东西：

image-20220403230656975

获取权限，从其执行的sql来看，其实际逻辑为：

用户->用户的角色->角色关联的菜单->返回菜单的权限字符。即：

sys_user -> sys_user_role -> sys_role_menu -> sys_menu

这样避免了空权限（我所指的空权限是有此权限而没有实际含义），即每个权限都有对应的菜单或按钮。