登錄&&權(quán)限流程圖

前言

首先我們確定的權(quán)限控制分為三大部分，其中根據(jù)粒度大小分的更細(xì)：

• 登錄權(quán)限控制
• 頁(yè)面權(quán)限控制
  • 菜單中的頁(yè)面是否可以被訪問(wèn)
  • 頁(yè)面中的按鈕 (增、刪、改、查)的權(quán)限控制是否顯示
• 接口權(quán)限控制

一、登錄權(quán)限控制

登錄訪問(wèn)權(quán)限控制是對(duì)用戶的校驗(yàn)。在用戶登錄成功之后，后臺(tái)將返回一個(gè)token，之后前端每次進(jìn)行接口請(qǐng)求的時(shí)候，都要帶上這個(gè)token。后臺(tái)拿到這個(gè)token后進(jìn)行判斷，如果此token確實(shí)存在并且沒(méi)有過(guò)期，則可以通過(guò)訪問(wèn)。如果token不存在或后臺(tái)判斷已過(guò)期，則會(huì)跳轉(zhuǎn)到登錄頁(yè)面，要求用戶重新登錄獲取token。

做法一

在用戶登錄成功的回調(diào)中將后臺(tái)返回的token直接存儲(chǔ)到localStorage，然后同步配置請(qǐng)求默認(rèn)參數(shù)的形式將token取出放入headers中傳給后臺(tái)。代碼如下：

  let axiosOptions = {
   method,
   url,
   data,
   timeout,
   // 'arraybuffer', 'blob', 'document', 'json', 'text', 'stream'。default json
   responseType,
   // 請(qǐng)求頭內(nèi)追加authToken屬性
   headers: {
    authtToken: window.localStorage.getItem(`base/token$$`)
   }
  }

做法二

當(dāng)前項(xiàng)目中使用axios.interceptors.request.use設(shè)置發(fā)送請(qǐng)求前的攔截,直接將token塞入req.headers.authToken中，作為全局傳入。代碼如下：

// axios.interceptors.request.use 請(qǐng)求攔截：配置發(fā)送請(qǐng)求的信息
// axios.interceptors.response.use 響應(yīng)攔截：配置請(qǐng)求回來(lái)的信息

axios.interceptors.request.use(req => {
 req.headers.authToken = window.localStorage.getItem(`base/token$$`)
 return req
}, error => {
 return Promise.reject(error)
})

登錄涉及到的知識(shí)點(diǎn)

• vuex + localStorage: 本地通過(guò)vuex+localStorage持久化存儲(chǔ)token(token:服務(wù)端創(chuàng)建用于唯一標(biāo)識(shí)用戶身份的Key)。
• axios: 請(qǐng)求攔截驗(yàn)證token，可以使用axios的API:axios.interceptors.request.use，也可以通過(guò)添加默認(rèn)參數(shù)的形式在請(qǐng)求頭中追加token。

二、頁(yè)面權(quán)限控制

上面已經(jīng)說(shuō)到，頁(yè)面權(quán)限控制又分為兩種：

• 菜單中的頁(yè)面是否可以被訪問(wèn)
• 頁(yè)面中的按鈕 (增、刪、改、查)的權(quán)限控制是否顯示

先看菜單的頁(yè)面訪問(wèn)權(quán)限

實(shí)現(xiàn)頁(yè)面訪問(wèn)權(quán)限又可分為以下兩種方案：

• 方案一、初始化即掛載全部路由，每次路由跳轉(zhuǎn)前做校驗(yàn)
• 方案二、只掛載當(dāng)前用戶擁有的路由，如果用戶通過(guò)URL進(jìn)行強(qiáng)制訪問(wèn)，則會(huì)直接進(jìn)入404，相當(dāng)于從源頭上做了控制

前者的缺點(diǎn)很明顯，每次路由跳轉(zhuǎn)都要做一遍檢驗(yàn)是對(duì)計(jì)算資源的浪費(fèi)，另外對(duì)于用戶無(wú)權(quán)訪問(wèn)的路由，理論上就不應(yīng)該掛載。

后者解決了上述問(wèn)題，但按需掛載路由就需要知道用戶的路由權(quán)限，也就是在用戶登錄進(jìn)來(lái)的時(shí)候就要知道當(dāng)前用戶擁有哪些路由權(quán)限。

所以肯定是方案二比較符合良好的用戶體驗(yàn)。

項(xiàng)目中的菜單權(quán)限控制

1.權(quán)限涉及到的meta屬性

• noRequireAuth: true 無(wú)需權(quán)限直接掛載
• manageFree: true 不在操作權(quán)限樹(shù)中展示

2.router.beforeEach()攔截路由的鉤子

• 不需要權(quán)限的路由直接放行。meta內(nèi)noRequireAuth和manageFree不受權(quán)限控制
• 進(jìn)入路由前，從后端請(qǐng)求獲取需要展示的菜單。后端根據(jù)token判斷當(dāng)前用戶權(quán)限，返回對(duì)應(yīng)菜單。前端遞歸對(duì)比確定最終要顯示的菜單列表

3.router.addRoutes()

• 通過(guò)router.addRoutes()動(dòng)態(tài)添加所有符合權(quán)限的路由

按鈕級(jí)權(quán)限控制(Vue指令v-permission)

1.每個(gè)模塊對(duì)應(yīng)有四種權(quán)限，查詢(get)，添加(post)，更新(put)，刪除(delete)
2.利用十進(jìn)制和二進(jìn)制來(lái)表示當(dāng)前模塊所擁有的權(quán)限。1111(15)，轉(zhuǎn)換后的二進(jìn)制與權(quán)限的關(guān)系表示：從右至左數(shù)(1代表?yè)碛性摍?quán)限，0代表不擁有)，第一位代表查詢，第二位代表添加，第三位代表更新，第四位代表刪除。如eg：二進(jìn)制1111(15)，代表用于查詢，添加，更新，刪除四種權(quán)限。

3.判斷對(duì)應(yīng)模塊沒(méi)有此權(quán)限時(shí)，移除當(dāng)前按鈕dom元素。

使用示例：

 <el-button @click="handleClick" v-permission:moduleName.post>新增</el-button>
 <el-button @click="handleClick" v-permission.delete="moduleName">刪除</el-button>

三、接口訪問(wèn)權(quán)限控制

最后再加上請(qǐng)求控制作為最后一道防線，路由可能配置失誤，按鈕可能忘了加權(quán)限，這種時(shí)候請(qǐng)求控制可以用來(lái)兜底，越權(quán)請(qǐng)求將在前端被攔截。

前后端約定接口采用RESTful風(fēng)格，同樣對(duì)應(yīng)四種權(quán)限，包括查詢（get），添加（post），更新（put），刪除（delete）。對(duì)于查詢操作，正常如果參數(shù)只有一個(gè)，應(yīng)該用get請(qǐng)求，如果有多個(gè)參數(shù)，需要改為post請(qǐng)求，但是需要在url后面添加/query以告訴服務(wù)端當(dāng)前進(jìn)行的是查詢操作，用于和正常的添加(post)請(qǐng)求區(qū)分。同樣的是，刪除用戶時(shí)如果有多個(gè)參數(shù)，DELETE請(qǐng)求同樣改為POST請(qǐng)求，在后面添加/delete用于和正常的刪除（delete）操作進(jìn)行區(qū)分。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評(píng)論