有关权限设计的思考

2017年8月24日

最近看公司的代码，对权限管理颇有兴趣，恰好今天有空，就记录并总结了一下，如果有错误，还望指正。

通过慕课网的一些课程，一遍的权限管理的表结构如下：

image-20210915100854997

从图上可以看出，表结构主要有User，Role，Function 三个表，分别对应用户、角色、功能，通过这三张表完成权限的控制和实现。这也是从传统的基于RBAC的角色权限空。

• User 与 Role 是多对多关系，使用第三方UserRole表来维护

• sRole 与 Function 同样也是多对多的关系，多个角色对应多个功能（每个模块都有对应的id，功能即模块，即menu），使用第三方表RoleFunction来维护

大概思路：

用户登陆时加载菜单，根据用户查询用户角色，根据用户角色查询用户功能，将查询到一个menu code，然后返回这些menu code

在控制层在根据menu code 获取并加载菜单。s

但是无法对每个menu 中的按钮权限进行控制（比如添加、删除、审核）

解决办法： 在Role和Function的第三方表中插入一列：menu_btn，代表该该角色下的功能拥有什么样的按钮权限

然后查询时，封装一个拥有menu_btn的实体类menu，用来记录权限，如果没有任何button，则不显示任何菜单

---

项目做法：

表结构：

T_SYS_USER 用户表

T_SYS_ROLE 角色表

T_SYS_USER_ROLE 用户角色关系表

T_SYS_MENU 功能表

T_SYS_ROLE_PRIVILEGE 按钮权限 

[关于权限按钮列表]:

系统有固化的权限按钮,新增,修改,删除,查看,审核..

名称对应:ADD_BTN,MOD_BTN,DEL_BTN,VIEW_BTN,AUDIT_BTN...应:ADD_BTN,MOD_BTN,DEL_BTN,VIEW_BTN,AUDIT_BTN...

多个用户对应多个角色 ， 使用第三方表T_SYS_USER_ROLE维护

---

权限管理中的授权问题：

一个用户可以对应多个角色，A角色的操作权限和B角色的操作权限有冲突，那该以谁的为准？

下面有几种解决方案：

1. 合并权限，将A角色的权限和B角色的权限合并 √

2. 在视图上给用户选择，让用户可以切换角色，操作麻烦 ×

3. 如果角色之间有授权冲突，则不允许授权 ×

4. 允许用户对冲突角色进行授予，让用户在授予权限时，设置角色的优先级，当角色冲突时，以优先级高的角色为准 √

公司代码分析：

// 定义一个map，用来保存菜单权限 
Map<String, MenuPrivilege> ret = new HashMap<String, MenuPrivilege>();
// 查询出权限并添加，使用sql直接查询menu，不查role，即不实例化role，即可避免这个问题，但是btns又拥有这个问题，待解决
List<SysRolePrivilege> priviletList = sysRolePrivilegeDao.findByUserRolePrivilege(userId);
for (SysRolePrivilege rp : priviletList) {  
  ret.put(rp.getMenuCode(), new MenuPrivilege(rp.getMenuCode(), rp.getMenuBtn()));
  // 相同的menu code会直接被map的唯一性覆盖
}
return ret;

问题解决，思路大概是按照解决方案一

新问题： btns问题

A role 对应 A menu - btn_add, btn_query

B role 对应 A menu - btn_add, btn_delete

如果Arole和Brole都赋给User1那么权限以谁的为准？

公司代码在这部分并没有处理，有可能是代码的bug，个人认为这个地方使用合并的方式比较合适。

关于菜单管理：

项目的权限管理是根据当前用户的类型，决定要显示的菜单 从而实现权限管理的功能。当加载menu时，会在控制层根据当前登陆用户获取菜单:

/* 功能菜单数据获取 */
@RequestMapping("tree")
@ResponseBody
public Object menuTree(HttpServletRequest request, HttpSession session) {
  ...
    // 从数据库中获取菜单数据
    List<SysMenu> list = menuService.menusOfUser(session);
  List<Map<String, String>> ret = new ArrayList<Map<String, String>>();
  for (SysMenu po : list) {
    Map<String, String> map = new HashMap<String, String>();
    map.put("id", po.getMenuCode());
    map.put("pid", po.getMenuPcode());
    map.put("name", po.getMenuName());
    if (po.isLeafYn()) { // 如果为叶子节点
      map.put("url", "menu/jump/" + po.getMenuCode()); // 点击链接
    } else {
      map.put("url", po.getMenuUrl());
    }
    ret.add(map);
  }
  return ret;   // 这里在mvc配置文件中配置了json转换器，spring mvc会自动帮你将集合转换为json字符串，发送给jsp，使用js进行菜单的显示
}

List<SysMenu> list = menuService.menusOfUser(session);

menusOfUser方法：

@Service("menuService") 
public class MenuService {
  public List<SysMenu> menusOfUser(HttpSession session) {
    SessionUser sessionUser = (SessionUser) session.getAttribute(SessionUser.SESSION_USER_KEY);
    Assert.notNull(sessionUser, "user information in session cannot be null");
    // 超级管理员
    if (SysUser.USER_TYPE_MASTER == sessionUser.getUserType()) {
      return menuList;
    }
    // 其他普通用户
    Map<String, MenuPrivilege> menus = sessionUser.getPrivilege();
    // 如果没有权限菜单，返回空
    if (menus == null || menus.size() == 0) {
      return new ArrayList<SysMenu>();
    }
    List<SysMenu> result = new ArrayList<SysMenu>();
    for (SysMenu sysMenu : menuList) {
      if (menus.containsKey(sysMenu.getMenuCode())) {
        result.add(sysMenu);
      }
    }
    return result;
  }
}

2019年9月12日

对权限有了新的理解，这家公司的权限系统相比较之前的设计的更成熟，同样是基于RABC的方式，但是不基于URL，基于对单个接口。

权限设计

在该系统中，每个http接口都称为一个交易TRANS，多个交易组成一个产品PRODUCT，而多个产品构成一个产品组PRODUCTGROUP。在给客户赋予权限时，会在后台管理系统中，将一个或者多个产品组/产品赋予客户。客户被赋予该产品的权限时，权限下的所有交易都是可访问的。

当用户登录时，会拉取所有已经授权的产品/产品组，并将这些产品/产品组对应的所有的交易(接口url)获取，并去重放置在用户session中。当用户访问某个交易时，会在责任链/顾虑器中判断此接口是否在用户的权限中，如果在放行，不在则会停止访问，告知用户无权限操作。

菜单设计

而关于多级菜单的控制，是统一放置在一张RULE表中，在表中包含如下几个信息，RULEID，RULETYPE，RULEDEF。比如有如下菜单：

用户
	用户管理
		添加用户
		删除用户
	用户配置

其数据在RULE的表现是这样的：

ruleid				ruletype				ruledef
root					menutree				user,product,xxx,...
user					menutree				usermanager, userconfig
usermanager 	menutree				useradd, userdelete
useradd				menu						prdid_useradd,user/add
userdelete		menu 						prdid_userdelete,user/delete
userconfig		menu 						prdid_userconfig, user/config

在项目中，会将所有ruletype=menu or ruletype=menutype的菜单数据取出，找到根菜单root，其中menutree代表该菜单不是叶子菜单，需要继续寻找其子菜单，子菜单的定义位于字段ruledef中。通过这种方式依次递归查找，当遇到类型为menu的数据时，说明菜单是叶子菜单，就停止向下层递归，并取出ruledef字段，这时，叶子菜单的ruledef字段，定义的信息就不再是子菜单了，而是该菜单对应的product id，而逗号后面的代表点击改菜单，需要跳转的接口地址。

当用户登录时，先取出所有产品信息，取出后，再生成菜单树，当用户没有菜单对应所需的产品的权限时，这个菜单就不会增加到菜单树中，故在页面上也无法获取到没有权限的菜单。

涉及的表

PRODUCTGROUP 		#产品组表
PRODUCT    			#产品表
PRODUCTGROUPPRODUCT #产品与产品组关联表
PRODUCTTRS 			#产品与交易关联表

RULE 						#规则表
PRODUCTUSER			#用户产品关联标

按钮权限

关于按钮权限的设计。在项目中，很少有对单个按钮的控制的，通常都是以菜单或者product作为控制权限。可以将某些按钮设置为一个产品，然后通过判断权限的方式（判断用户是否有次产品的权限），来决定是否展示相应的按钮或者地址。为了方便使用，项目还封装了一套jsp标签（老），以及前端组件（新、以及H5）。

此外，还可以通过对RULE表的控制来达到此效果。比如，在RULE表中定义要进行控制的RULEID，比如：

ruleid				ruletype				ruledef
useradd				button					
userdel				button	

然后通过表USERRULE，将用户可操作性的按钮写入，并通过共用组件判断用户是否有用该RULE实现。缺点是每一个要控制的按钮都要单独配置，并且与产品没有关联，管理起来较为困难，可适当的优化。

rule的其他作用

rule中文名称称为规则，所以rule表的功能远远不止于此。例如：

• 在查询客户账户列表的功能中，制定了一套规则，根据用户的类型，可限制可操作账户的类型

• 定义了某些业务的开始时间与结束时间，有点像配置中心

优点

1. 权限控制严格

2. 结构层次清晰

缺点

1. 因为将菜单、权限等信息配置在数据库中，所以没在新增一个接口、菜单等信息时，都要对应插入一堆复杂的SQL，因此上线总是出现问题。并且当菜单数据出现问题时，会导致所有功能展示都有问题（比如，所有功能缺失）

2. rule表中的数据在项目启动时仅仅加载一次，好处是rule表中的数据频繁读取，缓存在内存中减少系统压力。缺点是每次更改菜单都要重启服务，造成服务不可用

   个人认为的解决办法：增加状态SQL是否更改，如果SQL发生更改，就重新读取SQL缓存；或者将数据缓存在redis或者其他缓存中间件中，然后通过缓存控制刷新

3. 菜单信息无法进行版本控制，这个可以通过Flyway实现。