前端權限控制的本質
一般說來，權限管理可以分爲兩種情況：
第一種爲頁面級訪問權限。第一種情況是非常常見的，即用戶是否能夠看到頁面；
第二種爲數據級操作權限。第二種情況是用戶能否對數據進行增刪改查等操作。
這兩種情況在實際的前端表現中都是一致的，即用戶在正常頁面中看不見，看不見就不能操作，所以進行了一次視覺上的隔離。在這裏有的人可能會說：“你這不是自欺欺人嗎？視覺隔離有什麼用啊，有好多方法能夠繞過去的啊，比如改改代碼或者直接用ajax訪問”。是的，你說的對，這其實就是自欺欺人，不過這也正是我要說的：前端的權限控制實質上就是用於展示，讓操作變得更加友好，真正的安全實際上是由後端控制的。
這裏舉個例子簡單說明一下。如果用戶通過其他方式繞過了前端的路由控制，訪問到了該用戶原本不能訪問的頁面，然後呢？頁面中的數據需要從後端獲取，頁面中的操作也需要發送給後端，如果後端自身對於所有的請求接口有自己的權限控制，那麼用戶其實只能看到這個頁面中固有的那些信息。
這裏其實還有一個大家很容易想到的問題：在做接口測試時，如果系統本身有權限設置，但是接口未做權限，那麼測試直接使用API測試工具訪問的話…呵呵。所以說前端根本不用糾結於用戶以各種形式繞過頁面的問題，而以上這些問題在後端那裏則根本不是問題。
權限策略
在理解了前端權限的本質後，我們說一下前端的權限策略。依照我目前的瞭解，大致上把權限策略分爲以下兩種：
1.前端記錄所有的權限。用戶登錄後，後端返回用戶角色，前端根據角色自行分配頁面。優點是前端完全控制，想怎麼改就怎麼改；缺點是當角色越來越多時，可能會給前端路由編寫上帶來一定的麻煩。
2.前端僅記錄頁面，後端記錄權限。用戶登陸後，後端返回用戶權限列表，前端根據該列表生成可訪問頁面。優點是前端完全基於後端數據，後期幾乎沒有維護成本；缺點是爲了降低維護成本，必須擁有菜單配置頁面及權限分配頁面，否則就是噩夢。
本篇採用第二種方式：接口權限控制
上文中說到，前端權限控制中，真正能實現安全的是接口，所以先實現接口的權限控制，而且這裏聽上去很重要，但實際上卻很簡單。接口權限控制說白了就是對用戶的校驗。正常來說，在用戶登錄時服務器應給前臺返回一個token，以後前臺每次調用接口時都需要帶上這個token，服務端獲取到這個token後進行比對，如果通過則可以訪問。
我們通過對axios進行簡單的設置，增加請求攔截器，爲每個請求的Header信息中增加Token。以下爲僞代碼：
const service = axios.create()
// http request 攔截器
// 每次請求都爲http頭增加Authorization字段，其內容爲token
service.interceptors.request.use(
config => {
config.headers.Authorization = `${token}`
return config
}
);
export default service
這樣簡單的設置後即可實現在每次接口權限控制的前端部分。
接下來則是分別講述“頁面級訪問控制”和“數據級操作控制”的前端實現方式。如果對數據級操作控制不感興趣的可以直接跳過。
頁面級訪問權限控制
雖然頁面級訪問控制實質上應該是控制頁面是否顯示，但落在實際中則有兩種不同的情況：
1.顯示系統中所有菜單，當用戶訪問不在自己權限範圍內的頁面時提示權限不足。
2.只顯示當前用戶能訪問的菜單，如果用戶通過URL進行強制訪問，則會直接404。
至於第一種形式，個人認爲在用戶體驗上非常不好，但不排除有某些特殊場景會用到這種方式。而本篇的權限控制是基於第二種形式。
依據剛纔選定的方式，及上文中提到的權限策略，我們能夠聯想並梳理出一個大致的流程，這也是本篇中實際權限的流程：
登錄 ——> 獲取該用戶權限列表 ——> 根據權限列表生成能夠訪問的菜單 ——> 點擊菜單，進入頁面
數據級操作權限控制
數據操作權限的獲取方式，我能夠想到的是以下兩種：
用戶登錄後，獲取權限列表時，直接在該數據中體現
每次訪問頁面時請求後臺，獲取該頁面的數據操作權限列表
不管項目中具體採用哪一種方法，或者使用兩種方法的結合，其實現原理都是一樣的：即將返回的數據操作權限列表增加到路由表中的對應頁面的自定義字段中（如permission），然後在進入頁面前，根據該自定義字段來判斷頁面中的元素是否需要顯示。
這裏的核心點是：如何將數據放置到路由表中，以及如何根據路由表中的字段在頁面中進行判斷
忘記出處，以前筆記中摘錄，侵刪。