查看原文：前端權(quán)限驗證控制與實現(xiàn)

查看原文點擊關(guān)注“八戒技術(shù)團隊”，閱讀更多技術(shù)干貨

歡迎大家一起探討交流進入技術(shù)交流群

前言

在應(yīng)用中，”權(quán)限驗證“是一個常見的話題。從應(yīng)用的層面來講，雖然不同的應(yīng)用有一定區(qū)別，但總體不外乎以下四種權(quán)限狀態(tài)：游客、普通用戶、管理員用戶、超級管理員用戶；從技術(shù)的層面上來講，一個用戶具有什么樣的管理權(quán)限，應(yīng)當是該用戶的一個身份標識，而這樣的身份標識應(yīng)該是跟隨用戶信息一并存儲在數(shù)據(jù)庫中的數(shù)據(jù)。由此可見，用戶權(quán)限的設(shè)計本質(zhì)上來說應(yīng)當是后端工作的一部分。

但在真正應(yīng)用的過程中，卻并非是純后端的工作。首先站在產(chǎn)品經(jīng)理的角度，用戶使用什么樣的功能應(yīng)該在接觸應(yīng)用的時候就被展現(xiàn)出來，而交互功能的起始在前端；其次從用戶的角度來講，當某一個功能不能被使用時，此時應(yīng)用做出諸如“錯誤提示”、“重定向“ 等操作比直接返回一個錯誤數(shù)據(jù)擁有更好的用戶體驗；最后是減輕服務(wù)器壓力，對于沒有權(quán)限的操作直接在前端進行相應(yīng)的處理，更少的請求意味著服務(wù)器壓力更小。

綜上所述，前端權(quán)限驗證僅僅作為后端權(quán)限體系的一個必要補充。雖然是一個補充，但是十分必要，它的必要性體現(xiàn)在：產(chǎn)品功能的完善、用戶體驗的提升、以及服務(wù)器壓力的減輕等諸多方面。

前端的權(quán)限驗證又主要分為三大部分：登錄權(quán)限驗證、頁面權(quán)限驗證、請求權(quán)限驗證。本文主要結(jié)合Vue3、Vue-router4、以及Vuex 的后臺管理系統(tǒng)案例來進行舉例說明。

1、登陸權(quán)限驗證

從使用流程上來看，往往用戶進入應(yīng)用之后，首先是登錄的判斷，譬如在后臺管理系統(tǒng)中，用戶通過外鏈或輸入應(yīng)用的網(wǎng)址鏈接，此時應(yīng)用應(yīng)對當前的登錄狀態(tài)進行驗證。若已經(jīng)登陸了即跳轉(zhuǎn)到用戶需要的頁面，若如果沒有登陸，那么應(yīng)引導用戶到登錄頁先進行登錄操作。

從技術(shù)實現(xiàn)上來看，前端用戶登錄的本質(zhì)是將用戶信息（userName/passWord/token…）存儲在本地（cookie/session/localStorage）和發(fā)送請求驗證用戶信息的有效性，并根據(jù)返回結(jié)果對當前用戶的信息進行處理，從而判斷當前用戶是否已經(jīng)正確登錄。

例如當前首頁需要進行登錄攔截，用戶在未登錄的情況下需要跳轉(zhuǎn)到登錄界面進行操作，可在路由中直接重定向登錄頁面 。

1.1 頁面重定向

先定義好路由，在需要登錄權(quán)限的路由添加`meta`字段標識。

然后在 `router.beforeEach`中進行判斷，對需要登錄且未登錄的頁面進行重定向

1.2 頁面引導登陸

除了直接重定向以外，有時還需要對用戶進行引導。在`layout`文件目錄中定義一個`default.vue`組件，在components中定一個登錄引導組件 `guide.vue`,在`default.vue`中引入 `guide.vue `并進行登錄的判斷。

對于需要登錄才能夠看到的組件，最外層套用一層 `default.vue` 組件即

效果如下：

總結(jié)：根據(jù)用戶是否登錄判斷用戶是否能夠看到對應(yīng)的內(nèi)容有兩種做法：1、對router進行配置和重定向操作。2、為需要登錄才能看到的組件包裹一層登錄判斷的高階組件。

2、頁面權(quán)限驗證

頁面的權(quán)限，不僅涉及登錄的判斷，還要根據(jù)用戶在系統(tǒng)之中的角色進行判斷，但是思路大同小異。首先是在vuex中存入用戶的角色權(quán)限，然后在路由中進行權(quán)限過濾，或者封裝高階組件對目標頁面進行處理。

2.1 路由權(quán)限驗證

用戶登錄成功之后，后端接口返回給前端該賬號下?lián)碛械臋?quán)限列表，至于是什么角色應(yīng)該擁有什么權(quán)限，此邏輯統(tǒng)一為后端邏輯進行配置處理，假設(shè)登陸成功后返回的數(shù)據(jù)如下：（偽代碼）

即是說，用戶 kevin 有且只有`列表頁`,`詳情頁 ` 的訪問權(quán)限，此時應(yīng)該根據(jù)用戶擁有的權(quán)限來配置路由，生成一份符合當前用戶角色的路由表。該路由表應(yīng)該由兩部分構(gòu)成，一部分是無需角色認證即可訪問的路由即靜態(tài)路由，另一部分是由當前用戶權(quán)限確定的路由即動態(tài)路由（使用vue-router4中的API `router.addRoute(route)` ）。

當前用戶只能夠訪問角色允許的頁面，當用戶訪問不屬于當前角色的頁面時，由于沒有生成對應(yīng)的路由，所以用戶無法進入對應(yīng)的頁面，如果要再優(yōu)化一下，就應(yīng)該告知當前操作者沒有訪問權(quán)限，或引導用戶重定向到其他頁面（ 在 `router.beforeEach()`中進行判斷）。

2.2 按鈕權(quán)限驗證

除了整個頁面進行角色認證外，頁面中操作按鈕也應(yīng)當根據(jù)角色權(quán)限的不同而進行不同的展示，譬如一個列表頁面，普通用戶和和管理員都能夠進行訪問，但是普通用戶只能夠進行`查看`，管理員才能夠進行`修改`和`刪除`操作，此時前端就要在這些功能按鈕上進行權(quán)限控制和處理。

對于使用者來講，常見的操作無非四種——增刪改查，所以后端在返回用戶信息的時候，除了可見頁面的權(quán)限，還應(yīng)當返回當前用的操作權(quán)限。這里對操作權(quán)限的定義有兩種，第一種是對“增刪改查”進行二進制編碼的對應(yīng)，擁有權(quán)限是`1`,沒有權(quán)限是`0`,例如用戶擁有所有操作權(quán)限，那么對應(yīng)的數(shù)字應(yīng)該是 `0001` 即 15；第二種做法是對“增刪改查”進行字符串匹配，例如用戶擁有所有權(quán)限，那么對應(yīng)的編碼應(yīng)該是 `'CURD'`。采用哪種方式更加方便，這個視情況而定，本例中采用第二種方式進行介紹。例如，登陸之后后端返回的數(shù)據(jù)為：（偽代碼）

上述代碼中，不同的路由下對應(yīng)著不同的權(quán)限，那么在頁面的按鈕中應(yīng)該如何實現(xiàn)權(quán)限的判斷呢 常見的做法有三種，第一種是拿到用戶的權(quán)限，直接在頁面 `v-if` 進行判斷；第二種是應(yīng)用高階組件進行封裝；第三種是自定義指令。

（1）v-if 判斷

這種做法雖能實現(xiàn)功能，但是每次使用都要重寫，很冗余。

（2）高階組件

定義一個高階組件 `p-button` ，然后將邏輯封裝，利用 `props` 傳遞按鈕對應(yīng)權(quán)限

高階組件大大減少了使用的復雜度，將邏輯抽離并獨立出來，但是每一次使用都必須要引入組件，這個過程還是有些繁瑣。

（3）自定義指令（v-permission）

指令控制十分方便，但是內(nèi)部邏輯不便于更改，靈活性有所欠缺。

以上三種方式均能夠?qū)崿F(xiàn)以下效果：

總結(jié)：對比之后，v-if 簡單粗暴，功能雖能實現(xiàn)，但過程過于繁瑣；高階組件，處理靈活但使用稍稍繁瑣；自定義指令，使用足夠簡潔，但是不夠靈活。所以應(yīng)當根據(jù)使用的場景選擇適當?shù)膶崿F(xiàn)方式。

3、axios接口請求權(quán)限驗證

接口請求的權(quán)限驗證，是一個非必要的補充，其目的在于路由失效，并且指令也失效的情況下，仍然可以做到前端的請求攔截。

接口請求攔截分為兩步，第一步是請求攔截，第二步是響應(yīng)攔截。請求攔截的目的是在請求頭中添加登錄成功時獲取到的 `token`，響應(yīng)攔截是對后端返回的狀態(tài)碼進行二次封裝，實現(xiàn)更好的交互提示。

3.1 請求攔截

3.2 響應(yīng)攔截

結(jié)語：本文基本概括了前端權(quán)限驗證的三個方面，基本思路并不復雜。整個技術(shù)涉及全局狀態(tài)管理（vuex）、路由管理（vue-router）、組件化思想（抽離邏輯并封裝/自定義指令使用）、以及axios請求攔截。按照一般產(chǎn)品的使用流程，從用戶登錄，頁面切換、按鈕操作、請求發(fā)起等方面對用戶權(quán)限驗證介紹了相應(yīng)的解決方案。隨著技術(shù)的進步與更新，前端權(quán)限驗證還會有更多的方法與思路，希望本文能夠起到一定的參考作用。

希望以上內(nèi)容能對有需要的人有所幫助