簡述

近幾年隨著 react、angular、vue 等前端框架興起，前后端分離的架構迅速流行。但同時權限控制也帶來了問題。

網上很多前、后端分離權限僅僅都僅僅在描述前端權限控制、且是較簡單、固定的角色場景，滿足不了我們用戶、角色都是動態的場景。且僅僅前端進行權限控制并不是真正意義的權限控制，它只是減少頁面結構暴露、增強用戶體驗的功效。

場景

系統為后臺管理系統，包含了用戶創建、用戶登錄、用戶管理自己的資源。用戶經常會新增、刪除，也可以根據工作情況隨時調整頁面、功能權限，所以采用用戶-角色-頁面權限方案實現。

為什么不行：

1. 根據前端路由表顯示左側菜單，但 vue-router 的路由表主要為了組織代碼，經常我們所需要的菜單并非一致。比如某個前端路由 a 子路由有 b、c，但菜單中我們想要直接一級菜單就顯示 b、c 或者將 b、c 各放到其他菜單下。所以這種非常不靈活。

2. 一個路由是菜單還是頁面?是否需要顯示到菜單中?是否驗證權限?哪個角色或者用戶擁有權限?這些都需要寫到前端路由里面，一旦有任何權限變動就要大量調整代碼。

3. 如果權限寫死在前端，那么角色或者用戶必須已知且固定不變。比如頁面 1 的 meta 增加屬性標識可訪問的角色為 a 和 b。

頁面

一個頁面即一個前端頁面，比如首頁、用戶管理頁、資源管理頁等。

基本思路為：前端路由保持不變，數據庫存儲菜單結構、頁面權限控制(可以直接做成一個頁面來方便管理)等，前端根據數據庫中的菜單結構和權限信息來渲染一個菜單出來并只顯示其有權限的菜單，并在路由守衛中進行權限控制防止手動輸入 path 越權打開頁面。

1. 前端路由(vue-router)中需要正常創建頁面及路由。

2. 數據庫存儲菜單結構和頁面權限信息。

a. 菜單(目錄、非內容頁)可以自己創建，不必要求前端路由中有，因為這是指菜單的可視化的組織結構。

b. 頁面(內容頁)必須是前端路由中已有頁面，因為這是用戶需要訪問的內容。

c. 菜單和頁面組成上下級關系，一級可以是菜單也可以是內容頁，內容頁也可以放在菜單下，不可見的內容頁也可以放在一個普通內容頁下，這樣理論(需要頁面菜單樣式支持)可以組成無限級菜單。面包屑導航也根據此層級遞歸查詢得到。

d. 菜單和頁面的基本屬性包括 title(對應路由 title)、name(對應路由 name)、path(對應路由 path)、父級、類型(菜單/頁面)、是否可見(左側菜單欄是否顯示：部分頁面可能是頁面內的鏈接進去)、是否需要驗證權限(部分頁面比如首頁無需驗證權限大家都可以進入)。

e. 不需要控制權限且不需要顯示到左側菜單的路由這里可以不進行管理，比如 404 頁面等。

3. 前臺打開后獲取獲取數據庫的所有菜單、頁面及結構，根據是否登錄、是否需要驗證權限等進行控制，或無權限跳轉至登錄頁。

4. 用戶登錄成功后，再獲取用戶對應的的頁面權限列表，使用上一步獲得的所有頁面、結構和用戶擁有權限的列表渲染出一個菜單，只包含此用戶擁有權限的，提升用戶體檢，避免顯示大量用戶不能訪問的菜單影響使用和不必要的功能暴露。

5. 路由守衛中根據上一步獲得的權限列表判斷每個跳轉，無權限可返回 404 或無權限頁面，防止用戶手動輸入 path 越權訪問。

頁面管理：

頁面編輯：

功能

部分功能有事需要單獨控制權限，比如用戶管理頁面可能允許多個角色查看，但是其中的“創建用戶”功能只允許某一個角色使用，那么僅僅使用頁面權限是不夠。所以需要細粒度的功能權限控制。

網上的方案都是說：根據資源控制增、刪、改、查等等，比如針對用戶就是用戶的創建、修改、刪除、查詢等。但是在我的實際使用中發現并不切合實際，最起碼對像我這種管理后臺，資源并不單純的增刪改查，可能有其他地方的其他操作中也會對此用戶資源造成影響，比如禁用、刪除角色也要禁用、刪除用戶，那么這個權限到底屬于角色的權限還是屬于用戶的權限，或者后臺又改了，角色又影響了其他資源或者不再對用戶進行操作，都會影響權限控制。

所以更合理的方法應該為將每個功能單獨進行控制并和頁面進行關聯，且不限定必須是增、刪、改、查四種，可以任意定制，只需要與前后端開發約定一個唯一的標識即可。

如上的例子中，用戶管理頁面下有用戶各種功能，角色管理頁面中也有個角色禁用、刪除功能，可以分別定義標識為 role_disable、role_delete，如果擁有 role_delete 權限即可，即使沒有 user_delete 權限，也可以直接刪除用戶，否則就不要給其 role_delete 權限。

用戶登錄后，從數據庫獲取其所擁有的的權限列表并存入 vuex，包含頁面和功能對應關系，例如頁面 name 為 user：{user: ['user_delete', 'user_query']}，頁面中根據刪除按鈕可以v-if="hasPermission('user_delete')"判斷即可。

頁面功能管理：

獲取用戶擁有的權限：

角色

一個角色類似于一個身份或崗位，每個角色有自己的權限范圍。

• 一個角色可以擁有多個頁面權限。
• 一個角色可以擁有多個功能權限。

角色管理：

角色分配權限：

用戶

用戶可以創建、刪除，一個用戶隨時可能變更工作內容，或者身兼數職，所以可以為其分配一個或者多個角色，他擁有的角色的權限就是他的權限。此時已經可以打通權限前端的權限分配，用戶-角色-頁面權限、功能權限。

用戶管理：

用戶分配角色：

前端效果

前端頁面菜單效果：

后端權限

傳統前后端不分離的情況下，路由都在后端統一管理，簡單的方法比如用戶管理頁面 /user/ 那么他里面使用的接口都使用 /user/add、/user/delete 等相同前綴，那么只要判斷用戶擁有 /user/ 權限就可以訪問/user/*所有接口。

前后端分離后面臨的問題：

接口

方案：1. 需要控制權限的接口進行上傳管理(可以做成管理頁面)

2. 每個頁面和功能可以關聯多個接口，比如用戶頁面關聯了用戶查詢接口和用戶編輯接口，用戶刪除功能關聯用戶刪除接口

3. 后端對請求的路徑進行判斷，用戶->角色->頁面/功能->接口，擁有接口權限即允許訪問

4. 前后端分團隊開發，不容易一一對照，且前端有自己的路由(此路由受限于代碼組織結構)等等，無法使用傳統方式簡單處理

5. 相同的接口可能會被前端多個頁面多次利用。

接口管理：

頁面關聯接口、功能關聯接口：

請求的接口無權限時：

接口后端權限控制

后端控制其實很簡單，只要前面管理功能做好即可，基本邏輯為：

1. 用戶訪問接口。

2. 判斷用戶和當前 path，根據用戶->角色->頁面/功能->接口 得到當前用戶有權限的接口列表與當前path相比。

3. 若無權限(某些接口只需要登錄就能訪問的，比如獲取用戶姓名信息的需要排除在外)則直接返回失敗，前端全局捕獲后給出無權限提示。

總結

1. 用戶管理

a. 用戶增刪改查

b. 每個用戶分配一個或多個角色

2. 角色管理

a. 角色增刪改查

b. 每個角色分配一個或多個頁面、功能授權

3. 頁面管理

a. 頁面增刪改查

b. 標記頁面上下級結構、是否內容頁(需對應前端存在的路由頁面)、是否可見、是否控制權限等等。

c. 前端菜單、面包屑等對用戶可感知的內容根據此上下級結構等進行渲染，不必受限于前端代碼中的路由

d. 前端路由根據此權限表進行權限控制

4. 接口權限控制

a. 接口管理錄入需要控制權限的接口

b. 將接口分別關聯到頁面、功能

c. 擁有功能權限則擁有對應接口權限，擁有頁面權限則擁有對應的權限

d. 只要通過任意頁面和功能擁有接口的權限則可以訪問此接口