近幾年隨着react、angular、vue等前端框架興起，前后端分離的架構迅速流行。
但同時權限控制也帶來了問題。
網上很多前、后端分離權限僅僅都僅僅在描述前端權限控制、且是較簡單、固定的角色場景，滿足不了我們用戶、角色都是動態的場景。
且僅僅前端進行權限控制並不是真正意義的權限控制，它只是減少頁面結構暴露、增強用戶體驗的功效。
場景
系統為后台管理系統，包含了用戶創建、用戶登錄、用戶管理自己的資源。
用戶經常會新增、刪除，也可以根據工作情況隨時調整頁面、功能權限，所以采用用戶-角色-頁面權限方案實現。
為什么不行：
-
根據前端路由表顯示左側菜單，但vue-router的路由表主要為了組織代碼，經常我們所需要的菜單並非一致。 比如某個前端路由a子路由有b、c，但菜單中我們想要直接一級菜單就顯示b、c或者將b、c各放到其他菜單下。 所以這種非常不靈活。
-
一個路由是菜單還是頁面？ 是否需要顯示到菜單中？ 是否驗證權限？ 哪個角色或者用戶擁有權限？ 這些都需要寫到前端路由里面，一旦有任何權限變動就要大量調整代碼。
-
如果權限寫死在前端，那么角色或者用戶必須已知且固定不變。 比如頁面1的meta增加屬性標識可訪問的角色為a和b
頁面
一個頁面即一個前端頁面，比如首頁、用戶管理頁、資源管理頁等。
基本思路為：
前端路由保持不變，數據庫存儲菜單結構、頁面權限控制（可以直接做成一個頁面來方便管理）等，前端根據數據庫中的菜單結構和權限信息來渲染一個菜單出來並只顯示其有權限的菜單，並在路由守衛中進行權限控制防止手動輸入path越權打開頁面。
-
前端路由（vue-router）中需要正常創建頁面及路由。
-
數據庫存儲菜單結構和頁面權限信息，
-
-
菜單（目錄、非內容頁）可以自己創建，不必要求前端路由中有，因為這是指菜單的可視化的組織結構
-
頁面（內容頁）必須是前端路由中已有頁面，因為這是用戶需要訪問的內容。
-
菜單和頁面組成上下級關系，一級可以是菜單也可以是內容頁，內容頁也可以放在菜單下，這樣理論（需要頁面菜單樣式支持）可以組成無限級菜單
-
菜單和頁面的基本屬性包括title（對應路由title）、name（對應路由name）、path（對應路由path）、父級、類型（菜單/頁面）、是否可見（左側菜單欄是否顯示： 部分頁面可能是頁面內的鏈接進去）、是否需要驗證權限（部分頁面比如首頁無需驗證權限大家都可以進入）
-
不需要控制權限且不需要顯示到左側菜單的路由這里可以不進行管理，比如404頁面等
-
-
前台打開后獲取獲取數據庫的所有菜單、頁面及結構，根據是否登錄、是否需要驗證權限等進行控制，或無權限跳轉至登錄頁
-
用戶登錄成功后，再獲取用戶對應的的頁面權限列表，使用上一步獲得的所有頁面、結構和用戶擁有權限的列表渲染出一個菜單，只包含此用戶擁有權限的，提升用戶體檢，避免顯示大量用戶不能訪問的菜單影響使用和不必要的功能暴露。
-
路由守衛中根據上一步獲得的權限列表判斷每個跳轉，無權限可返回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')"判斷即可。
關注微信公眾號：
Java技術棧，在后台回復：
架構，可以獲取我整理的 N 篇最新架構教程，都是干貨。
頁面功能管理：
獲取用戶擁有的權限：
角色
一個角色類似於一個身份或崗位，每個角色有自己的權限范圍。
-
一個角色可以擁有多個頁面權限。
-
一個角色可以擁有多個功能權限。
角色管理：
角色分配權限：
用戶
用戶可以創建、刪除，一個用戶隨時可能變更工作內容，或者身兼數職，所以可以為其分配一個或者多個角色，他擁有的角色的權限就是他的權限。
此時已經可以打通權限前端的權限分配，用戶-角色-頁面權限、功能權限。
用戶管理：
用戶分配角色：
前端效果
前端頁面菜單效果：
后端權限
傳統前后端不分離的情況下，路由都在后端統一管理，簡單的方法比如用戶管理頁面/user/那么他里面使用的接口都使用/user/add、/user/delete等相同前綴，那么只要判斷用戶擁有/user/權限就可以訪問/user/*所有接口。
前后端分離后面臨的問題：
接口
方案：
-
需要控制權限的接口進行上傳管理（可以做成管理頁面）
-
每個頁面和功能可以關聯多個接口，比如用戶頁面關聯了用戶查詢接口和用戶編輯接口，用戶刪除功能關聯用戶刪除接口
-
后端對請求的路徑進行判斷，用戶->角色->頁面/功能->接口，擁有接口權限即允許訪問
-
前后端分團隊開發，不容易一一對照，且前端有自己的路由（此路由受限於代碼組織結構）等等，無法使用傳統方式簡單處理
-
相同的接口可能會被前端多個頁面多次利用
來源：www.yuque.com/zhanghaofei/blog/xrpz9p
- END -
推薦閱讀：