Vue-Access-Control 前端使用者權限控制解決方案，

Vue-Access-Control 前端使用者權限控制解決方案，

Vue-Access-Control是一套基於Vue/Vue-Router/axios 實現的前端使用者權限控制解決方案，通過對路由、視圖、請求三個層面的控制，使開發人員可以實現任意顆粒度的使用者權限控制。

整體思路

會話開始之初，先初始化一個只有登入路由的Vue執行個體，在根組件created鉤子裡將路由定向到登入頁，使用者登入成功後前端拿到使用者token，設定axios執行個體統一為請求headers添加{"Authorization":token}實現使用者鑒權，然後擷取目前使用者的許可權資料，主要包括路由許可權和資源許可權，之後動態添加路由，產生菜單，實現許可權指令和全域許可權驗證方法，並為axios執行個體添加請求攔截器，至此完成許可權控制初始化。動態載入路由後，路由群組件將隨之載入並渲染，而後展現前端介面。

為解決瀏覽器重新整理路由重設的問題，拿到token後要將其儲存到sessionStorage，根組件的created鉤子負責檢查本地是否已有token，如果有則無需登入直接用該token擷取許可權並初始化，如果token有效且當前路由有權訪問，將載入路由群組件並正確展現；若當前路由無權訪問將按路由設定跳轉404；如果token失效，後端應返回4xx狀態代碼，前端統一為axios執行個體添加錯誤攔截器，遇到4xx狀態代碼執行退出操作，清除sessionStorage資料並跳轉到登入頁，讓使用者重新登入。

最小依賴原則

Vue-Access-Control的定位是單一領域解決方案，除了Vue/Vue-Router/axios之外沒有其他依賴，理論上可以無障礙的應用到任何有許可權控制需求的Vue項目中，項目基於webpack 模板開發構建，大多數新項目可以直接基於檢出代碼繼續開發。需要說明的是，項目額外引入的Element-UI和CryptoJS僅用於開發示範介面，他們不是必須且與許可權控制毫無關係，項目應用中可以自行取捨。

目錄結構

src/ |-- api/     //介面檔案 |  |-- index.js    //輸出通用axios執行個體 |  |-- account.js   //按業務模組組織的介面檔案，所有介面都引用./index提供的axios執行個體 |-- assets/ |-- components/ |-- router/ |  |-- fullpath.js   //完整路由資料，用於匹配使用者的路由許可權得到實際路由 |  `-- index.js   //輸出基礎路由執行個體 |-- views/ |-- App.vue ·-- main.js

資料格式約定

路由許可權資料必須是如下格式的對象數組，id和parent_id相同的兩個路由具有上下級關係，如果希望使用自訂格式的路由資料，需要修改路由控制的相關實現，詳見路由控制資料格式約定

[ {  "id": "1",  "name": "菜單1",  "parent_id": null,  "route": "route1" }, {  "id": "2",  "name": "菜單1-1",  "parent_id": "1",  "route": "route2" } ]　

　資源許可權資料必須是如下格式的對象數組，每個對象代表一個RESTful請求，支援帶參數的url，具體格式說明見請求控制

[ {  "id": "2c9180895e172348015e1740805d000d",  "name": "帳號-擷取",  "url": "/accounts",  "method": "GET" }, {  "id": "2c9180895e172348015e1740c30f000e",  "name": "帳號-刪除",  "url": "/account/**",  "method": "DELETE" }]　

路由控制

路由控制包括動態註冊路由和動態產生菜單兩部分。

動態註冊路由

最初執行個體化的路由僅包括登入和404兩個路徑，我們期待完整的路由是這樣的：

[{ path: '/login', name: 'login', component: (resolve) => require(['../views/login.vue'], resolve)}, { path: '/404', name: '404', component: (resolve) => require(['../views/common/404.vue'], resolve)}, { path: '/', name: '首頁', component: (resolve) => require(['../views/index.vue'], resolve), children: [{ path: '/route1', name: '欄目1', meta: {  icon: 'icon-channel1' }, component: (resolve) => require(['../views/view1.vue'], resolve) }, { path: '/route2', name: '欄目2', meta: {  icon: 'ico-channel2' }, component: (resolve) => require(['../views/view2.vue'], resolve), children: [{  path: 'child2-1',  name: '子欄目2-1',  meta: {     },  component: (resolve) => require(['../views/route2-1.vue'], resolve) }] }]}, { path: '*', redirect: '/404'}]

那麼接下來就需要擷取首頁以及其子路由們，思路是事先在本地存一份整個項目的完整路由資料，然後根據使用者權限對完整路由進行篩選。

篩選的實現思路是先將後端返回的路由資料處理成如下雜湊結構：

let hashMenus = { "/route1":true, "/route1/route1-1":true, "/route1/route1-2":true, "/route2":true, ...}

然後遍曆本地完整路由，在迴圈中將路徑拼接成上述結構中的key格式，通過hashMenus[route]就可以判斷路由是否匹配，具體實現見App.vue檔案中的getRoutes()方法。

如果後端返回的路由許可權資料與約定不同，就需要自行實現篩選邏輯，只要能得到實際可用的路由資料就可以，最終使用addRoutes()方法將他們動態添加到路由執行個體中，注意404頁面的模糊比對一定要放在最後。

動態菜單

路由資料可以直接用來產生導覽功能表，但路由資料是在根組件中得到的，導覽功能表存在於index.vue組件中，顯然我們需要通過某種方式共用菜單資料，方法有很多，一般來說首先想到的是Vuex，但菜單資料在整個使用者會話過程中不會發生改變，這並不是Vuex的最佳使用情境，而且為了盡量減少不必要的依賴，這裡用了最簡單直接的方法，把菜單資料掛在根組件data.menuData上，在首頁裡用this.$parent.menuData擷取。

另外，導覽功能表很可能會有添加欄目表徵圖的需求，這可以通過在路由中添加meta資料實現，例如將表徵圖class或unicode存到路由meta裡，模板中就可以訪問到meta資料，用來產生表徵圖標籤。

在多角色系統中可能遇到的一個問題是，不同角色有一個名字相同但功能不同的路由，比如說系統管理員和企業管理員都有”帳號管理”這個路由，但他們的操作許可權和目標不同，實際上是兩個完全不同的介面，而Vue不允許多個路由同名，因此路由的name必須做區分，但把區分後的name顯示在前端菜單上會很不美觀，為了讓不同角色可以享有同一個菜單名稱，我們只要將這兩個路由的meta.name都設定成”帳號管理”，在模板迴圈時優先使用meta.name就可以了。

菜單的具體實現可以參考views/index.vue。

視圖控制

視圖控制的目標是根據目前使用者許可權決定介面元素顯示與否，典型情境是對各種操作按鈕的顯示控制。實現視圖控制的本質是實現一個許可權驗證方法，輸入請求許可權，輸出是否獲准。然後配合v-if或jsx或自訂指令就能靈活實現各種視圖控制。

全域驗證方法

驗證方法的的實現本身很簡單，無非是根據後端給出的資源許可權做判斷，重點在於最佳化方法的輸入輸出，提升易用性，經過實踐總結最終使用的方案是，將許可權跟請求同時維護，驗證方法接收請求對象數組為參數，返回是否具有許可權的布爾值。

請求對象格式：

//擷取賬戶列表const request = { p: ['get,/accounts'], r: params => { return instance.get(`/accounts`, {params}) }}

許可權驗證方法$_has()的調用格式：

v-if="$_has([request])"

許可權驗證方法的具體實現見App.vue中Vue.prototype.$_has方法。

將許可權驗證方法全域混入，就可以在項目中很容易的配合v-if實現元素顯示控制，這種方式的優點在於靈活，除了可以校正許可權外，還可以在判斷運算式中加入運行時狀態做更多樣性的判斷，而且可以充分利用v-if響應資料變化的特點，實現動態視圖控制。

具體實現細節參考基於Vue實現後台系統許可權控制中的相關章節。

自訂指令

v-if的響應特性是把雙刃劍，因為判斷運算式在運行過程中會頻繁觸發，但實際上在一個使用者會話周期內其許可權並不會發生變化，因此如果只需要校正許可權的話，用v-if會產生大量不必要的運算，這種情況只需在視圖載入時校正一次即可，可以通過自訂指令實現：

//許可權指令Vue.directive('has', { bind: function(el, binding) { if (!Vue.prototype.$_has(binding.value)) {  el.parentNode.removeChild(el); } }});　

　自訂指令內部仍然是調用全域驗證方法，但優點在於只會在元素初始化時執行一次，多數情況下都應該使用自訂指令實現視圖控制。

請求控制

請求控制是利用axios攔截器實現的，目的是將越權請求在前端攔截掉，原理是在請求攔截器中判斷本次請求是否符合使用者權限，以決定是否攔截。

普通請求的判斷很容易，遍曆後端返回的的資源許可權格式，直接判斷request.method和request.url是否吻合就可以了，對於帶參數的url需要使用萬用字元，這裡需要根據項目需求前後端協商一致，約定好萬用字元格式後，攔截器中要先將帶參數的url處理成約定格式，再判斷許可權，方案中已經實現了以下兩種萬用字元格式：

1. 格式：/resources/:id 樣本：/resources/1 url: /resources/** 解釋：一個名詞後跟一個參數，參數通常表示名詞的id 2. 格式：/store/:id/member 樣本：/store/1/member url：/store/*/member

   解釋：兩個名詞之間夾帶一個參數，參數通常表示第一個名詞的id　

對於第一種格式需要注意的是，如果你要發起一個url為"/aaa/bbb"的請求，預設會被處理成"/aaa/**"進行許可權校正，如果這裡的”bbb”並不是參數而是url的一部分，那麼你需要將url改成"/aaa/bbb/"，在最後加一個”/“表示該url不需要轉化格式。

攔截器的具體實現見App.vue中的setInterceptor()方法。

如果你的項目還需要其他的萬用字元格式，只需要在攔截器中實現對應的檢測和轉化方法就可以了。

示範及說明

示範說明：

DEMO項目中示範了動態菜單、動態路由、按鈕許可權、請求攔截。

示範項目後端由rap2產生mock資料，登入請求通常應該是POST方式，但因為rap2的編程模式無法擷取到非GET的請求參數，因此只能用GET方式登入，實際項目中不建議仿效；

另外登入後擷取許可權的介面本來不需要攜帶額外參數，後端可以根據要求標頭攜帶的token資訊實現使用者鑒權，但因為rap2的編程模式擷取不到headers資料，因此只能增加一個”Authorization”參數用於產生類比資料。

測試帳號:　　

1. username: root password: 任意2. username: client password: 任意

示範地址:

vue-access-control.refined-x.com

總結

以上所述是小編給大家介紹的Vue-Access-Control 前端使用者權限控制解決方案，希望對大家有所協助，如果大家有任何疑問請給我留言，小編會及時回複大家的。在此也非常感謝大家對幫客之家網站的支援！