手把手教你搞定選單許可權設計,精確到按鈕級別

程式設計師志哥發表於2023-02-01

一、介紹

在實際的專案開發過程中,選單許可權功能可以說是後端管理系統中必不可少的一個環節,根據業務的複雜度,設計的時候可深可淺,但無論怎麼變化,設計的思路基本都是圍繞著使用者、角色、選單進行相應的擴充套件

今天小編就和大家一起來討論一下,怎麼設計一套可以精確到按鈕級別的選單許可權功能,廢話不多說,直接開擼!

二、資料庫設計

先來看一下,使用者、角色、選單表對應的ER圖,如下:

其中,使用者和角色是多對多的關係角色與選單也是多對多的關係使用者透過角色來關聯到選單,當然也有的業務系統選單許可權模型,是可以直接透過使用者關聯到選單,對選單許可權可以直接控制到使用者級別,不過這個都不是問題,這個也可以進行擴充套件。

對於使用者、角色表比較簡單,下面,我們重點來看看選單表的設計,如下:

可以看到,整個選單表就是一個樹型結構,關鍵欄位說明

  • menu_code:選單編碼,用於後端許可權控制
  • parent_id:選單父節點ID,方便遞迴遍歷選單
  • node_type:節點型別,可以是資料夾、頁面或者按鈕型別
  • link_url:頁面對應的地址,如果是資料夾或者按鈕型別,可以為空
  • level:選單樹的層次,以便於查詢指定層級的選單
  • path:樹id的路徑,主要用於存放從根節點到當前樹的父節點的路徑,逗號分隔,想要找父節點會特別快

為了後面方便開發,我們先建立一個名為menu_auth_db的資料庫,初始指令碼如下:

CREATE DATABASE IF NOT EXISTS menu_auth_db default charset utf8mb4 COLLATE utf8mb4_unicode_ci;

CREATE TABLE menu_auth_db.tb_user (
  id bigint(20) unsigned NOT NULL COMMENT '訊息給過來的ID',
  mobile varchar(20) NOT NULL DEFAULT '' COMMENT '手機號',
  name varchar(100) NOT NULL DEFAULT '' COMMENT '姓名',
  password varchar(128) NOT NULL DEFAULT '' COMMENT '密碼',
  is_delete tinyint(4) NOT NULL DEFAULT '0' COMMENT '是否刪除 1:已刪除;0:未刪除',
  PRIMARY KEY (id),
  KEY idx_name (name) USING BTREE,
  KEY idx_mobile (mobile) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='使用者表';

CREATE TABLE menu_auth_db.tb_user_role (
  id bigint(20) unsigned NOT NULL COMMENT '主鍵',
  user_id bigint(20) NOT NULL COMMENT '使用者ID',
  role_id bigint(20) NOT NULL COMMENT '角色ID',
  PRIMARY KEY (id),
  KEY idx_user_id (user_id) USING BTREE,
  KEY idx_role_id (role_id) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='使用者角色表';

CREATE TABLE menu_auth_db.tb_role (
  id bigint(20) unsigned NOT NULL COMMENT '主鍵',
  code varchar(100) NOT NULL DEFAULT '' COMMENT '編碼',
  name varchar(100) NOT NULL DEFAULT '' COMMENT '名稱',
  is_delete tinyint(4) NOT NULL DEFAULT '0' COMMENT '是否刪除 1:已刪除;0:未刪除',
  PRIMARY KEY (id),
  KEY idx_code (code) USING BTREE,
  KEY idx_name (name) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='角色表';


CREATE TABLE menu_auth_db.tb_role_menu (
  id bigint(20) unsigned NOT NULL COMMENT '主鍵',
  role_id bigint(20) NOT NULL COMMENT '角色ID',
  menu_id bigint(20) NOT NULL COMMENT '選單ID',
  PRIMARY KEY (id),
  KEY idx_role_id (role_id) USING BTREE,
  KEY idx_menu_id (menu_id) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='角色選單關係表';


CREATE TABLE menu_auth_db.tb_menu (
  id bigint(20) NOT NULL COMMENT '主鍵',
  name varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' COMMENT '名稱',
  menu_code varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' COMMENT '選單編碼',
  parent_id bigint(20) DEFAULT NULL COMMENT '父節點',
  node_type tinyint(4) NOT NULL DEFAULT '1' COMMENT '節點型別,1資料夾,2頁面,3按鈕',
  icon_url varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '圖示地址',
  sort int(11) NOT NULL DEFAULT '1' COMMENT '排序號',
  link_url varchar(500) COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '頁面對應的地址',
  level int(11) NOT NULL DEFAULT '0' COMMENT '層次',
  path varchar(2500) COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '樹id的路徑 整個層次上的路徑id,逗號分隔,想要找父節點特別快',
  is_delete tinyint(4) NOT NULL DEFAULT '0' COMMENT '是否刪除 1:已刪除;0:未刪除',
  PRIMARY KEY (id) USING BTREE,
  KEY idx_parent_id (parent_id) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='選單表';

三、後端開發

選單許可權模組的資料庫設計,一般5張表就可以搞定,真正有點複雜的地方在於資料的寫入和渲染,當然如果老闆突然讓你來開發一套選單許可權系統,我們也沒必要慌張,下面,我們一起來看看後端應該如何開發。

3.1、建立專案

為了方便快捷,小編我採用的是springboot+mybatisPlus元件來快速開發,直接利用mybatisPlus官方提供的快速生成程式碼的demo,一鍵生成所需的daoserviceweb層的程式碼,結果如下:

3.2、編寫選單新增服務

@Override
public void addMenu(Menu menu) {
    //如果插入的當前節點為根節點,parentId指定為0
    if(menu.getParentId().longValue() == 0){
        menu.setLevel(1);//根節點層級為1
        menu.setPath(null);//根節點路徑為空
    }else{
        Menu parentMenu = baseMapper.selectById(menu.getParentId());
        if(parentMenu == null){
            throw new CommonException("未查詢到對應的父節點");
        }
        menu.setLevel(parentMenu.getLevel().intValue() + 1);
        if(StringUtils.isNotEmpty(parentMenu.getPath())){
            menu.setPath(parentMenu.getPath() + "," + parentMenu.getId());
        }else{
            menu.setPath(parentMenu.getId().toString());
        }
    }
    //可以使用雪花演算法,生成ID
    menu.setId(System.currentTimeMillis());
    super.save(menu);
}

新增選單比較簡單,直接將資料插入即可,需要注意的地方是parent_idlevelpath,這三個欄位的寫入,如果新建的是根節點,預設parent_id0,方便後續遞迴遍歷。

3.3、編寫選單後端查詢服務

  • 新建一個選單檢視實體類
@Data
@EqualsAndHashCode(callSuper = false)
@Accessors(chain = true)
public class MenuVo implements Serializable {

    private static final long serialVersionUID = -4559267810907997111L;

    /**
     * 主鍵
     */
    private Long id;

    /**
     * 名稱
     */
    private String name;

    /**
     * 選單編碼
     */
    private String menuCode;

    /**
     * 父節點
     */
    private Long parentId;

    /**
     * 節點型別,1資料夾,2頁面,3按鈕
     */
    private Integer nodeType;

    /**
     * 圖示地址
     */
    private String iconUrl;

    /**
     * 排序號
     */
    private Integer sort;

    /**
     * 頁面對應的地址
     */
    private String linkUrl;

    /**
     * 層次
     */
    private Integer level;

    /**
     * 樹id的路徑 整個層次上的路徑id,逗號分隔,想要找父節點特別快
     */
    private String path;

    /**
     * 子選單集合
     */
    List<MenuVo> childMenu;
}
  • 編寫選單查詢服務,使用遞迴重新封裝選單檢視
@Override
public List<MenuVo> queryMenuTree() {
    Wrapper queryObj = new QueryWrapper<>().orderByAsc("level","sort");
    List<Menu> allMenu = super.list(queryObj);
    // 0L:表示根節點的父ID
    List<MenuVo> resultList = transferMenuVo(allMenu, 0L);
    return resultList;
}
/**
 * 封裝選單檢視
 * @param allMenu
 * @param parentId
 * @return
 */
private List<MenuVo> transferMenuVo(List<Menu> allMenu, Long parentId){
    List<MenuVo> resultList = new ArrayList<>();
    if(!CollectionUtils.isEmpty(allMenu)){
        for (Menu source : allMenu) {
            if(parentId.longValue() == source.getParentId().longValue()){
                MenuVo menuVo = new MenuVo();
                BeanUtils.copyProperties(source, menuVo);
                //遞迴查詢子選單,並封裝資訊
                List<MenuVo> childList = transferMenuVo(allMenu, source.getId());
                if(!CollectionUtils.isEmpty(childList)){
                    menuVo.setChildMenu(childList);
                }
                resultList.add(menuVo);
            }
        }
    }
    return resultList;
}
  • 編寫一個選單樹查詢介面,如下:
@RestController
@RequestMapping("/menu")
public class MenuController {

    @Autowired
    private MenuService menuService;

    @PostMapping(value = "/queryMenuTree")
    public List<MenuVo> queryTreeMenu(){
        return menuService.queryMenuTree();
    }
}

為了便於演示,我們先初始化7條資料,如下圖:

其中最後三條是按鈕型別,等下會用於後端許可權控制,介面查詢結果如下:

這個服務是針對後端管理介面查詢的,會將所有的選單全部查詢出來以便於進行管理,展示結果類似如下圖:

這個圖片截圖於小編正在開發的一個專案,內容可能不一致,但是資料結構基本都是一致的

3.4、編寫使用者選單許可權查詢服務

在上面,我們介紹到了使用者透過角色來關聯選單,因此,很容易想到,流程如下:

  • 第一步:先透過使用者查詢到對應的角色;
  • 第二步:然後再透過角色查詢到對應的選單;
  • 第三步:最後將選單查詢出來之後進行渲染;

實現過程相比選單查詢服務多了前2個步驟,過程如下:

@Override
public List<MenuVo> queryMenus(Long userId) {
    //1、先查詢當前使用者對應的角色
    Wrapper queryUserRoleObj = new QueryWrapper<>().eq("user_id", userId);
    List<UserRole> userRoles = userRoleService.list(queryUserRoleObj);
    if(!CollectionUtils.isEmpty(userRoles)){
        //2、透過角色查詢選單(預設取第一個角色)
        Wrapper queryRoleMenuObj = new QueryWrapper<>().eq("role_id", userRoles.get(0).getRoleId());
        List<RoleMenu> roleMenus = roleMenuService.list(queryRoleMenuObj);
        if(!CollectionUtils.isEmpty(roleMenus)){
            Set<Long> menuIds = new HashSet<>();
            for (RoleMenu roleMenu : roleMenus) {
                menuIds.add(roleMenu.getMenuId());
            }
            //查詢對應的選單
            Wrapper queryMenuObj = new QueryWrapper<>().in("id", new ArrayList<>(menuIds));
            List<Menu> menus = super.list(queryMenuObj);
            if(!CollectionUtils.isEmpty(menus)){
                //將選單下對應的父節點也一併全部查詢出來
                Set<Long> allMenuIds = new HashSet<>();
                for (Menu menu : menus) {
                    allMenuIds.add(menu.getId());
                    if(StringUtils.isNotEmpty(menu.getPath())){
                        String[] pathIds = StringUtils.split(",", menu.getPath());
                        for (String pathId : pathIds) {
                            allMenuIds.add(Long.valueOf(pathId));
                        }
                    }
                }
                //3、查詢對應的所有選單,並進行封裝展示
                List<Menu> allMenus = super.list(new QueryWrapper<Menu>().in("id", new ArrayList<>(allMenuIds)));
                List<MenuVo> resultList = transferMenuVo(allMenus, 0L);
                return resultList;
            }
        }

    }
    return null;
}
  • 編寫一個使用者選單查詢介面,如下:
@PostMapping(value = "/queryMenus")
public List<MenuVo> queryMenus(Long userId){
    //查詢當前使用者下的選單許可權
    return menuService.queryMenus(userId);
}

有的同學,可能覺得沒必要存放path這個欄位,的確在某些場景下不需要。

為什麼要存放這個欄位呢?

小編在跟前端進行對接的時候,發現這麼一個問題,有些前端的樹型元件,在勾選子集的時候,不會將對應的父ID傳給後端,例如,我在勾選【列表查詢】的時候,前端無法將父節點【選單管理】ID也傳給後端,所有後端實際存放的是一個尾節點,需要一個欄位path,來存放節點對應的父節點路徑。

其實,前端也可以傳,只不過需要修改元件的屬性,前端修改完成之後,樹型元件就無法全選,不滿足業務需求。

所以,有些時候得根據實際得情況來進行取捨。

3.5、編寫後端許可權控制

後端進行許可權控制目標,主要是為了防止無許可權的使用者,進行介面請求查詢。

其中選單編碼menuCode就是一個前、後端聯絡的橋樑,細心的你會發現,所有後端的介面,與前端對應的都是按鈕操作,所以我們可以以按鈕為基準,實現前後端雙向控制

以【角色管理-查詢】這個為例,前端可以透過選單編碼實現是否展示這個查詢按鈕,後端可以透過選單編碼來判斷,當前使用者是否具備請求介面的許可權。

以後端為例,我們只需編寫一個許可權註解和代理攔截器即可!

  • 編寫一個許可權註解
@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface CheckPermissions {

    String value() default "";
}
  • 編寫一個代理攔截器,攔截有@CheckPermissions註解的方法
@Aspect
@Component
public class CheckPermissionsAspect {

    @Autowired
    private MenuMapper menuMapper;

    @Pointcut("@annotation(com.company.project.core.annotation.CheckPermissions)")
    public void checkPermissions() {}

    @Before("checkPermissions()")
    public void doBefore(JoinPoint joinPoint) throws Throwable {
        Long userId = null;
        Object[] args = joinPoint.getArgs();
        Object parobj = args[0];
        //使用者請求引數實體類中的使用者ID
        if(!Objects.isNull(parobj)){
            Class userCla = parobj.getClass();
            Field field = userCla.getDeclaredField("userId");
            field.setAccessible(true);
            userId = (Long) field.get(parobj);
        }
        if(!Objects.isNull(userId)){
            //獲取方法上有CheckPermissions註解的引數
            Class clazz = joinPoint.getTarget().getClass();
            String methodName = joinPoint.getSignature().getName();
            Class[] parameterTypes = ((MethodSignature)joinPoint.getSignature()).getMethod().getParameterTypes();
            Method method = clazz.getMethod(methodName, parameterTypes);
            if(method.getAnnotation(CheckPermissions.class) != null){
                CheckPermissions annotation = method.getAnnotation(CheckPermissions.class);
                String menuCode = annotation.value();
                if (StringUtils.isNotBlank(menuCode)) {
                    //透過使用者ID、選單編碼查詢是否有關聯
                    int count = menuMapper.selectAuthByUserIdAndMenuCode(userId, menuCode);
                    if(count == 0){
                        throw new CommonException("介面無訪問許可權");
                    }
                }
            }
        }
    }
}
  • 我們以【角色管理-查詢】為例,先新建一個請求實體類RoleDto,新增使用者ID屬性
@Data
@EqualsAndHashCode(callSuper = false)
@Accessors(chain = true)
public class RoleDto extends Role {

    //新增使用者ID
    private Long userId;
}
  • 在需要的介面上,新增@CheckPermissions註解,增加許可權控制
@RestController
@RequestMapping("/role")
public class RoleController {

    private RoleService roleService;

    @CheckPermissions(value="roleMgr:list")
    @PostMapping(value = "/queryRole")
    public List<Role> queryRole(RoleDto roleDto){
        return roleService.list();
    }

    @CheckPermissions(value="roleMgr:add")
    @PostMapping(value = "/addRole")
    public void addRole(RoleDto roleDto){
        roleService.add(roleDto);
    }

    @CheckPermissions(value="roleMgr:delete")
    @PostMapping(value = "/deleteRole")
    public void deleteRole(RoleDto roleDto){
        roleService.delete(roleDto);
    }
}

依次類推,當我們想對某個介面進行許可權控制的時候,只需要新增一個註解@CheckPermissions,並填寫對應的選單編碼即可!

四、使用者許可權測試

我們先初始化一個使用者【張三】,然後給他分配一個角色【訪客人員】,同時給這個角色分配一下2個選單許可權【系統配置】、【使用者管理】,等會用於許可權測試。

初始內容如下:

資料初始化完成之後,我們來啟動專案,傳入使用者【張三】的ID,查詢使用者具備的選單許可權,結果如下:

查詢結果,使用者【張三】有兩個選單許可權!

接著,我們來驗證一下,使用者【張三】是否有角色查詢許可權,請求角色查詢介面如下:

因為沒有配置角色查詢介面,所以無權訪問!

五、總結

整片內容,只介紹了後端關鍵的服務實現過程,可能也有遺漏的地方,歡迎網友點評、吐槽!

相關文章