摘要：基本設(shè)計(jì)和分析前端服務(wù)端主要功能打開思否頁(yè)面，根據(jù)頁(yè)面的功能點(diǎn)，設(shè)計(jì)出相關(guān)的數(shù)據(jù)表，和管理系統(tǒng)需要的相關(guān)頁(yè)面。

本文主要想對(duì)前端權(quán)限管理功能實(shí)現(xiàn)做一個(gè)分享，所以并不會(huì)對(duì)后臺(tái)管理的框架結(jié)構(gòu)做太詳細(xì)介紹，如果有朋友對(duì)其他有興趣可以留言。

前端 vue + elementui

服務(wù)端: node + mysql + nginx

打開思否頁(yè)面，根據(jù)頁(yè)面的功能點(diǎn)，設(shè)計(jì)出相關(guān)的數(shù)據(jù)表，和管理系統(tǒng)需要的相關(guān)頁(yè)面。
計(jì)劃后臺(tái)管理需要完成的功能：

權(quán)限管理（菜單權(quán)限到數(shù)據(jù)權(quán)限） -- 已完成

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

socket （對(duì)用戶點(diǎn)贊，評(píng)論，系統(tǒng)通知等消息進(jìn)行實(shí)時(shí)推送）-- 未完成

文件管理（將頁(yè)面需要用到的文件上傳管理，其他頁(yè)面都統(tǒng)一訪問文件庫(kù)資源）-- 已完成

基本業(yè)務(wù) （業(yè)務(wù)頁(yè)面）-- 部分完成

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

進(jìn)入正文，關(guān)于權(quán)限設(shè)計(jì)，圍繞的是前端頁(yè)面，但是會(huì)將前端和后端的邏輯都講出來(lái)。

前端頁(yè)面

看圖中圈起來(lái)的地方，前端看到的邏輯是這樣的：

當(dāng)前用戶為admin

樹用右鍵操作是admin創(chuàng)建的用戶

樹用右鍵操作創(chuàng)建的用戶admin可以管理

就是創(chuàng)建了一個(gè)用戶，這個(gè)用戶創(chuàng)建的用戶以及創(chuàng)建用戶創(chuàng)建的用戶，都可以被當(dāng)前創(chuàng)建者管理。

接口邏輯

查詢到數(shù)據(jù)庫(kù)中所有的用戶ID

通過(guò)用戶ID和創(chuàng)建人ID的關(guān)系，通過(guò)建立樹狀數(shù)據(jù)，得到當(dāng)前用戶創(chuàng)建的用戶樹

遞歸從用戶樹中得到所有屬于當(dāng)前用戶子集的用戶ID

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

通過(guò)這個(gè)邏輯，可以得到所有當(dāng)前用戶創(chuàng)建的子集，但是第一步有很大的問題，一旦用戶數(shù)量巨大，這樣查詢會(huì)很慢。母目前只是為了功能實(shí)現(xiàn)，暫未考慮到性能方面，如果有好的方法，希望指點(diǎn)。

前端頁(yè)面

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

不存在直接刪除

存在需要先將當(dāng)前創(chuàng)建的用戶轉(zhuǎn)移給其他用戶（其他用戶不可為他的子集）

將用戶轉(zhuǎn)移成功,則此時(shí)子集為空 ->2

接口邏輯

查詢到數(shù)據(jù)庫(kù)中是否存在創(chuàng)建人ID為當(dāng)前要?jiǎng)h除的用戶ID

存在則無(wú)法刪除當(dāng)前用戶

前端調(diào)用戶轉(zhuǎn)移接口，將當(dāng)前用戶創(chuàng)建的用戶轉(zhuǎn)移給其他人后，此時(shí)可刪除該用戶

菜單設(shè)計(jì)的時(shí)候分為三個(gè)類型，管理平臺(tái)，論壇，移動(dòng)端，但是不一定會(huì)寫完，感覺一個(gè)人寫好累呀~~~~
通過(guò)菜單又分還有默認(rèn)布局組件和頁(yè)面組件的區(qū)分，布局組件為layout，頁(yè)面組件則為他的子路由，通過(guò)嵌套的形式，組成一個(gè)完整的頁(yè)面。

目前頁(yè)面上都是通過(guò)右鍵點(diǎn)擊樹組件，進(jìn)入操作，如圖所示，可以對(duì)菜單進(jìn)行增刪改查操作。

菜單字段的定義和相關(guān)用處
字段定義是這樣的：
看到圖中有這些字段，對(duì)主要字段說(shuō)明：

菜單編碼（對(duì)應(yīng)前端頁(yè)面的文件名，比如userMan, 渲染時(shí)就會(huì)找到 */userMan/index去resolve）

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

-- ----------------------------
-- 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. 管理平臺(tái)菜單 2. BBS菜單 3. 移動(dòng)端菜單",
  `code` VARCHAR(48) NOT NULL COMMENT "菜單編碼",
  `name` VARCHAR(48) NOT NULL COMMENT "菜單名稱",
  `component` tinyint(4) NOT NULL COMMENT "對(duì)應(yīng)組件: -1. 根節(jié)點(diǎn) 1. 頁(yè)面組件 2.默認(rèn)布局 3456...擴(kuò)展布局",
  `icon` VARCHAR(128) DEFAULT NULL COMMENT "菜單圖標(biāo)",
  `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 "狀態(tài): 0：停用，1：?jiǎn)⒂?默認(rèn)為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 "狀態(tài): 0：刪除，1：可用(默認(rèn)為1)",
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT="菜單表";

    id: "", // *唯一ID
    pid: "", // *父ID
    type: "", // *菜單類型
    code: "", // *菜單編碼
    name: "", // *菜單名稱
    component: "", // *菜單組件
    icon: "", // 菜單圖標(biāo)
    redirect: "", // 重定向路徑
    sort: "", // *排序
    desc: "", // 描述
    status: 1 // *狀態(tài): 0：停用，1：?jiǎn)⒂?默認(rèn)為1)"

有什么用處呢和好處呢，就個(gè)人而言，就是覺得把路由表放在數(shù)據(jù)庫(kù)，讓項(xiàng)目更易于維護(hù)，在頁(yè)面中通過(guò)一個(gè)匹配邏輯，可以將所有字段組裝成為可以使用的路由表:

// 得到頁(yè)面路徑
function getPath (arr, child, code) {
  const pItem = arr.find(item => child.pid === item.id)
  // 當(dāng)前元素還存在父節(jié)點(diǎn), 且父節(jié)點(diǎn)不為根節(jié)點(diǎn)
  if (arr.find(item => pItem.pid === item.id && item.pid > -1)) {
    getPath(arr, pItem, `${pItem.code}/${code}`)
  } else {
    return `${pItem.code}/${code}`
  }
}
// 對(duì)基礎(chǔ)數(shù)據(jù)的處理
              item.meta = {}
              item.meta.title = item.name
              item.meta.icon = item.icon
              item.meta.id = item.id
              // 使路由名字具有唯一性
              item.name = item.name + index
              // 設(shè)置對(duì)應(yīng)的頁(yè)面路徑
              item.path = "/" + item.code
// 設(shè)置頁(yè)面對(duì)應(yīng)的組件 對(duì)應(yīng)組件: -1. 根節(jié)點(diǎn) 1. 頁(yè)面組件 2.默認(rèn)布局 3456...擴(kuò)展布局
              switch (item.component) {
                case -1:
                  console.log("根節(jié)點(diǎn)，已經(jīng)過(guò)濾掉了")
                  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
              }

通過(guò)這種方式，在設(shè)置頁(yè)面權(quán)限的時(shí)候，只需要接口設(shè)置當(dāng)前角色對(duì)應(yīng)的菜單，用戶查詢的時(shí)候能獲取到的就是當(dāng)前分配給他的權(quán)限，將這個(gè)權(quán)限組裝成路由表，即可。

上面說(shuō)的是菜單的配置，以及生成。然后和每個(gè)頁(yè)面相關(guān)的數(shù)據(jù)權(quán)限，需要點(diǎn)擊到頁(yè)面級(jí)別的菜單才可以訪問到，如圖：

選中一個(gè)菜單之后，可以對(duì)這個(gè)菜單添加數(shù)據(jù)權(quán)限的控制，比如添加，編輯，刪除等操作。

數(shù)據(jù)權(quán)限的實(shí)現(xiàn)

主要是字段設(shè)計(jì)，所以對(duì)圖中字段（開發(fā)人員錄入）詳細(xì)說(shuō)明:

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

功能api （接口編碼，后端通過(guò)判斷用戶是否存在這個(gè)編碼，來(lái)判斷是否存在操作權(quán)限）

請(qǐng)求方式 (restfulApi情況下，因?yàn)閍pi編碼相同，需要根據(jù)請(qǐng)求方式來(lái)判斷用戶的操作權(quán)限)

前端實(shí)現(xiàn)

分配完權(quán)限之后，前端頁(yè)面在對(duì)應(yīng)的按鈕或要操作的dom上，通過(guò)v-if 功能編碼是否存在來(lái)設(shè)置操作權(quán)限的顯示隱藏。
但是前端的顯隱一旦用戶繞過(guò)頁(yè)面去訪問接口即可，所以數(shù)據(jù)權(quán)限前端只是操作顯隱，具體實(shí)現(xiàn)還在后端。

后端實(shí)現(xiàn)

做一個(gè)數(shù)據(jù)權(quán)限中間層，用戶訪問時(shí)中間層判斷當(dāng)前訪問的接口用戶是否擁有權(quán)限

怎么判斷，通過(guò)前端設(shè)置的功能api和請(qǐng)求方式，去表中查詢當(dāng)前用戶角色是否可訪問

可訪問繼續(xù)往下走，不能訪問就拒絕了

用戶存在了，菜單和數(shù)據(jù)權(quán)限也配置好了，但是需要角色去將他們關(guān)聯(lián)到一起。

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

同樣是右鍵，可以開始對(duì)角色進(jìn)行分配權(quán)限的操作

左邊是頁(yè)面的權(quán)限分配，選中頁(yè)面之后，右邊會(huì)出現(xiàn)數(shù)據(jù)權(quán)限的分配:

繼承式的分配權(quán)限

總共有100個(gè)權(quán)限

a有50個(gè)，a給b分配時(shí)，只能分配50個(gè)

假設(shè)a給b分配了30個(gè)，c為b的下級(jí)，d為c的下級(jí)

c此時(shí)無(wú)權(quán)限，a或b能分配30個(gè)給c，但由于c無(wú)權(quán)限，a或b分配給d時(shí)，分配的列表為空

創(chuàng)建用戶
創(chuàng)建菜單
創(chuàng)建角色
用戶綁定角色，角色分配權(quán)限
完成

案例地址

node服務(wù)