前端權限控制_yin_you_yu的博客-CSDN博客_前端權限控制框架 https://blog.csdn.net/yin_you_yu/article/details/80408340
1 前端權限控制具體指什麼
前端權限歸根結底是請求的發起權，請求的發起可能由頁面加載觸發，也可能由頁面上的按鈕點擊觸發。
總的來說，所有的請求發起都觸發自前端路由或視圖，所以我們可以從這兩方面入手，對觸發權限的源頭進行控制，最終要實現的目標是：
-
路由方面，用戶登錄後只能看到自己有權訪問的導航菜單，也只能訪問自己有權訪問的路由地址，否則將跳轉 4xx 提示頁；
-
視圖方面，用戶只能看到自己有權瀏覽的內容和有權操作的控件；
-
最後再加上請求控制作爲最後一道防線，路由可能配置失誤，按鈕可能忘了加權限，這種時候請求控制可以用來兜底，越權請求將在前端被攔截。
2 怎麼做前端權限控制
控制的第一步是知道用戶擁有哪些權限，所以用戶登錄後第一件事是獲取權限數據。
權限數據至少應該包括路由權限和資源權限。
路由權限，就是用戶可訪問的路由集合，以此作爲設置前端路由和生成導航菜單的依據；
資源權限是用戶可訪問的資源集合，“資源” 概念來自 RESTful 架構，如果對 “資源” 感到陌生也可以簡單理解成用戶能夠發起的所有請求集合，以此作爲視圖控制和請求攔截的依據。
這裏插入講一下 “角色” 這個概念，可能有的系統會通過角色來做權限控制，我理解的角色就是特定幾個資源打包後的快捷方式。
引入角色這個概念的好處是，後臺可以通過賦角色的方式，很方便的爲某一類用戶賦予特定的資源集合，而角色的作用應該僅限於此，尤其不應該將角色用做前端權限控制的依據，因爲角色背後的資源權限是後端動態可配的。
我們也可以創建一個名字叫做 “總經理” 的角色，但其實一個資源都沒有，所以前端應該始終關注資源權限本身，而只將角色視爲用戶的一個普通屬性就好了。
有了權限數據，下一步就是分別-實現對路由、視圖、請求的控制。
2.1 路由控制
首先要實現動態菜單，這樣就可以對常規訪問方式進行限制；對於非常規訪問方式比如手動修改 url，可以從前端路由處着手做控制。
路由控制的思路有兩種，一種是初始化，即掛載全部路由，每次路由跳轉前做校驗；
另一種是只掛載用戶擁有的路由，相當於從源頭上做了控制。
前者的缺點很明顯，每次路由跳轉都要做一遍校驗是對計算資源的浪費，另外對於用戶無權訪問的路由，理論上就不應該掛載。
後者解決了上述問題，但仔細想這裏存在一個悖論，要按需掛載路由就需要知道用戶的路由權限，要知道用戶的路由權限就需要用戶先登錄進來，但路由沒有加載應用也沒有初始化，用戶從哪兒登錄？
這裏又可以有兩種解決思路，一種是單獨做一個登錄頁，登錄後帶着用戶憑據跳轉到前端應用；另一種是先初始化一個只有登錄路由的應用，用戶登錄後動態添加路由，當然這需要框架提供支持。
2.2 視圖控制
需要實現一個可以在視圖層調用權限驗證方法，輸入用戶期望的權限，輸出是否擁有該權限，將調用這個方法的結果，作爲界面上需要驗證權限的控件或元素顯示與否的依據。
2.3 請求控制
實際上就是爲你使用的 HTTP 庫實現一個請求攔截器，對將要發起的請求與用戶資源權限進行匹配，攔截越權請求。
這裏值得一提的是對於攜帶參數的 url，需要先進行模式約定，比如/people/1這個 url 可以在權限中描述爲/people/**，那麼攔截器中就要先將這種 url 處理成約定後的格式，然後再進行權限驗證。
