摘要：基本設計和分析前端服務端主要功能打開思否頁面，根據頁面的功能點，設計出相關的數據表，和管理系統需要的相關頁面。

本文主要想對前端權限管理功能實現做一個分享，所以并不會對后臺管理的框架結構做太詳細介紹，如果有朋友對其他有興趣可以留言。

前端 vue + elementui

服務端: node + mysql + nginx

打開思否頁面，根據頁面的功能點，設計出相關的數據表，和管理系統需要的相關頁面。
計劃后臺管理需要完成的功能：

權限管理（菜單權限到數據權限） -- 已完成

工作流 （問答和文章在某個條件內，提交需要走流程）-- 未完成

socket （對用戶點贊，評論，系統通知等消息進行實時推送）-- 未完成

文件管理（將頁面需要用到的文件上傳管理，其他頁面都統一訪問文件庫資源）-- 已完成

基本業務 （業務頁面）-- 部分完成

├── admin                      // 打包產出文件
├── node_module                // npm加載所需的項目依賴模塊
├── public                     // 靜態入口
├── src                        // 源代碼
│?? ├── api                    // 所有請求
│?? ├── assets                 // 主題 字體 圖片等靜態資源
│?? ├── common                 // 全局公用配置
│   │   ├── config             // 配置全局路由權限和錯誤捕獲
│   │   ├── mixin              // 一些vue公用的mixin
│   │   ├── js                 // 編寫公有的方法
│   │   └── style              // 編寫公有的樣式
│?? ├── components             // 全局公用組件
│?? ├── directive              // 自定義指令
│?? ├── router                 // 路由
│?? ├── store                  // 全局 store管理
│?? ├── views                  // view
│?? ├── App.vue                // 入口頁面
│?? └── main.js                // 入口 加載組件 初始化等
├── static                     // 第三方不打包資源
├── .babelrc                   // babel-loader 配置
├── eslintrc.js                // eslint 配置項
├── .gitignore                 // git 忽略項
├── vue.config.js              // vue-cli@3.0+ 配置文件
└── package.json               // package.json

進入正文，關于權限設計，圍繞的是前端頁面，但是會將前端和后端的邏輯都講出來。

前端頁面

看圖中圈起來的地方，前端看到的邏輯是這樣的：

當前用戶為admin

樹用右鍵操作是admin創建的用戶

樹用右鍵操作創建的用戶admin可以管理

就是創建了一個用戶，這個用戶創建的用戶以及創建用戶創建的用戶，都可以被當前創建者管理。

接口邏輯

查詢到數據庫中所有的用戶ID

通過用戶ID和創建人ID的關系，通過建立樹狀數據，得到當前用戶創建的用戶樹

遞歸從用戶樹中得到所有屬于當前用戶子集的用戶ID

select * from table where id in (子集用戶id)

通過這個邏輯，可以得到所有當前用戶創建的子集，但是第一步有很大的問題，一旦用戶數量巨大，這樣查詢會很慢。母目前只是為了功能實現，暫未考慮到性能方面，如果有好的方法，希望指點。

前端頁面

刪除用戶，調用接口判斷用戶是否有子集，存在->3，不存在->2

不存在直接刪除

存在需要先將當前創建的用戶轉移給其他用戶（其他用戶不可為他的子集）

將用戶轉移成功,則此時子集為空 ->2

接口邏輯

查詢到數據庫中是否存在創建人ID為當前要刪除的用戶ID

存在則無法刪除當前用戶

前端調用戶轉移接口，將當前用戶創建的用戶轉移給其他人后，此時可刪除該用戶

菜單設計的時候分為三個類型，管理平臺，論壇，移動端，但是不一定會寫完，感覺一個人寫好累呀~~~~
通過菜單又分還有默認布局組件和頁面組件的區分，布局組件為layout，頁面組件則為他的子路由，通過嵌套的形式，組成一個完整的頁面。

目前頁面上都是通過右鍵點擊樹組件，進入操作，如圖所示，可以對菜單進行增刪改查操作。

菜單字段的定義和相關用處
字段定義是這樣的：
看到圖中有這些字段，對主要字段說明：

菜單編碼（對應前端頁面的文件名，比如userMan, 渲染時就會找到 */userMan/index去resolve）

菜單組件 (指的是layout等，后面如果需要做多布局，通過這個設置頁面即可有不同布局)

-- ----------------------------
-- bbs_menu
-- ----------------------------
DROP TABLE IF EXISTS `bbs_menu`;
CREATE TABLE `bbs_menu` (
  `id` INT(11) NOT NULL AUTO_INCREMENT,
  `pid` INT(11) DEFAULT "0",
  `type` tinyint(4) NOT NULL DEFAULT "1" COMMENT "菜單類型: 1. 管理平臺菜單 2. BBS菜單 3. 移動端菜單",
  `code` VARCHAR(48) NOT NULL COMMENT "菜單編碼",
  `name` VARCHAR(48) NOT NULL COMMENT "菜單名稱",
  `component` tinyint(4) NOT NULL COMMENT "對應組件: -1. 根節點 1. 頁面組件 2.默認布局 3456...擴展布局",
  `icon` VARCHAR(128) DEFAULT NULL COMMENT "菜單圖標",
  `alias` VARCHAR(128) DEFAULT NULL COMMENT "別名",
  `redirect` VARCHAR(128) DEFAULT NULL COMMENT "重定向路徑: 配置菜單編碼或URL",
  `sort` INT(11) NOT NULL,
  `desc` VARCHAR(128) DEFAULT NULL,
  `status` tinyint(4) NOT NULL DEFAULT "1" COMMENT "狀態: 0：停用，1：啟用(默認為1)",
  `create_user` INT(11) DEFAULT NULL,
  `create_time` datetime DEFAULT NULL,
  `update_user` INT(11) DEFAULT NULL,
  `update_time` datetime DEFAULT NULL,
  `delete_user` INT(11) DEFAULT NULL,
  `delete_time` datetime DEFAULT NULL,
  `flag` tinyint(4) NOT NULL DEFAULT "1" COMMENT "狀態: 0：刪除，1：可用(默認為1)",
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT="菜單表";

    id: "", // *唯一ID
    pid: "", // *父ID
    type: "", // *菜單類型
    code: "", // *菜單編碼
    name: "", // *菜單名稱
    component: "", // *菜單組件
    icon: "", // 菜單圖標
    redirect: "", // 重定向路徑
    sort: "", // *排序
    desc: "", // 描述
    status: 1 // *狀態: 0：停用，1：啟用(默認為1)"

有什么用處呢和好處呢，就個人而言，就是覺得把路由表放在數據庫，讓項目更易于維護，在頁面中通過一個匹配邏輯，可以將所有字段組裝成為可以使用的路由表:

// 得到頁面路徑
function getPath (arr, child, code) {
  const pItem = arr.find(item => child.pid === item.id)
  // 當前元素還存在父節點, 且父節點不為根節點
  if (arr.find(item => pItem.pid === item.id && item.pid > -1)) {
    getPath(arr, pItem, `${pItem.code}/${code}`)
  } else {
    return `${pItem.code}/${code}`
  }
}
// 對基礎數據的處理
              item.meta = {}
              item.meta.title = item.name
              item.meta.icon = item.icon
              item.meta.id = item.id
              // 使路由名字具有唯一性
              item.name = item.name + index
              // 設置對應的頁面路徑
              item.path = "/" + item.code
// 設置頁面對應的組件 對應組件: -1. 根節點 1. 頁面組件 2.默認布局 3456...擴展布局
              switch (item.component) {
                case -1:
                  console.log("根節點，已經過濾掉了")
                  break
                case 1:
                  item.component = resolve => require([`@/views/${getPath(menu, item, item.code)}/index`], resolve)
                  break
                case 2:
                  item.component = Layout
                  break
                default:
                  item.component = resolve => require(["@/views/errorPage/401"], resolve)
                  break
              }

通過這種方式，在設置頁面權限的時候，只需要接口設置當前角色對應的菜單，用戶查詢的時候能獲取到的就是當前分配給他的權限，將這個權限組裝成路由表，即可。

上面說的是菜單的配置，以及生成。然后和每個頁面相關的數據權限，需要點擊到頁面級別的菜單才可以訪問到，如圖：

選中一個菜單之后，可以對這個菜單添加數據權限的控制，比如添加，編輯，刪除等操作。

數據權限的實現

主要是字段設計，所以對圖中字段（開發人員錄入）詳細說明:

功能編碼 （頁面編碼:功能編碼，主要用于前端控制顯隱）

功能api （接口編碼，后端通過判斷用戶是否存在這個編碼，來判斷是否存在操作權限）

請求方式 (restfulApi情況下，因為api編碼相同，需要根據請求方式來判斷用戶的操作權限)

前端實現

分配完權限之后，前端頁面在對應的按鈕或要操作的dom上，通過v-if 功能編碼是否存在來設置操作權限的顯示隱藏。
但是前端的顯隱一旦用戶繞過頁面去訪問接口即可，所以數據權限前端只是操作顯隱，具體實現還在后端。

后端實現

做一個數據權限中間層，用戶訪問時中間層判斷當前訪問的接口用戶是否擁有權限

怎么判斷，通過前端設置的功能api和請求方式，去表中查詢當前用戶角色是否可訪問

可訪問繼續往下走，不能訪問就拒絕了

用戶存在了，菜單和數據權限也配置好了，但是需要角色去將他們關聯到一起。

這里設置的邏輯是一個用戶只能綁定一個角色。
角色管理頁面，還是右鍵樹組件，可以看到綁定用戶的選項

同樣是右鍵，可以開始對角色進行分配權限的操作

左邊是頁面的權限分配，選中頁面之后，右邊會出現數據權限的分配:

繼承式的分配權限

總共有100個權限

a有50個，a給b分配時，只能分配50個

假設a給b分配了30個，c為b的下級，d為c的下級

c此時無權限，a或b能分配30個給c，但由于c無權限，a或b分配給d時，分配的列表為空

創建用戶
創建菜單
創建角色
用戶綁定角色，角色分配權限
完成

案例地址

node服務