『壹』 前端許可權控制-基於vue-router的動態路由實現
在中後台應用系統開發中，大部分情況下會涉及到用戶許可權控制，除了後端做許可權驗證外，前端在用戶訪問時也需要基於用戶許可權做相應控制。針對前端使用vue框架的情況，對頁面一級的許可權控制，常規處理是在頁面導航欄通過控制導航顯隱控制許可權，但在瀏覽器地址欄輸入訪問路徑依然可以訪問，可以用vue-router的動態路由來實現許可權控制。
登錄成功後通過addRoutes更新路由配置
正常情況下這樣就可以實現動態路由控制了，但刷新頁面發現會出現404，因為刷新時vue實例重新初始化了，導致動態路由被還原成默認路由，此時需要將許可權碼存儲在本地，在main.js中根據許可權碼重新生成動態路由
以上步驟基本可以實現動態添加路由並在刷新頁面是維持路由狀態，但訪問根路徑會始終跳轉到登錄頁，無法默認跳轉到首頁，這個問題目前還未想到好的解決方案。
『貳』 vue項目許可權管理
首先，許可權管理 般需求是兩個： 許可權和按鈕許可權。
前端 案會把所有路由信息在前端配置，通過路由守衛要求 戶登錄， 戶登錄後根據 過濾出路由表。 如我會配置 個 asyncRoutes 數組，需要認證的 在其路由的 meta 中添加 個 roles 欄位，等獲取 戶 之後取兩者的交集，若結果不為空則說明可以訪問。此過濾過程結束，剩下的路由就是該 戶能訪問的 ，最後通過 router.addRoutes(accessRoutes) 式動態添加路由即可。
後端 案會把所有 路由信息存在資料庫中， 戶登錄的時候根據其 查詢得到其能訪問的所有 路由信息返回給前端，前端再通過 addRoutes 動態添加路由信息。
按鈕許可權的控制通常會實現 個指令，例如 v-permission ，將按鈕要求 通過值傳給v-permission指令，在指令的 moutned 鉤 中可以判斷當前 戶 和按鈕是否存在交集，有則保留按鈕， 則移除按鈕。
路由守衛 permission.js ：
路由 成## permission.js ：
動態追加路由## permission.js ：
服務端返回的路由信息如何添加到路由器中？
『叄』 react 高階組件實現按鈕許可權顯示與隱藏實現
一些管理端通過不同許可權對按鈕進行控制與隱藏,這個功能很普遍吧。自己記錄一下自己在react端的實現方式-主要使用高階組件方式；
當然咯 這是我們這邊返回的數據介面是這樣的。每個按鈕也有唯一的BtnCode
這樣可以做到通用組件，不同頁面的許可權控制
控制前端按鈕的顯示隱藏就可以實現了。當然完全的許可權按鈕 還需要後台小夥伴的配合。 此文僅供參考。希望可以幫助到有需要的小夥伴們~
『肆』 談前端許可權
自從有了前後端分離，前端的工作內容就變得越發多起來，其中有一項就是許可權控制，下面就談一談前端許可權。
首先我們要理清前端許可權是什麼，我理解的前端許可權就是 控制前端元素是否可見 。因為之前後台模板時代，我們的頁面都是通過後台來渲染的，能不能訪問到頁面直接由後台邏輯判斷就好。但是現在我們到了前後端分離時代，所有頁面的元素都由頁面本身來控制，所以頁面路由這塊需要由前端本身來控制了。所以我認為前端許可權有這幾個關鍵點：
下面我們說一說為什麼說 前端只能做視覺上的控制 和 許可權控制不能放在前端，後台還是需要對每一個介面做驗權 。我覺得其實WEB本身就是圍繞數據來的，所以我們前端安全，主要是保護我們的 數據 ，那和數據最緊密接觸的其實還是後台，前端本身做得是 數據的展示和收集 ，但是數據的存儲和處理並不是由前端來做。所以即使前端能控制住路由/按鈕等不被別人看到，發送請求的方式還是有很多，完全可以繞過前端來請求數據。所以從某種意義上來說，就算前端的許可權控製做得再嚴密，可能作用也是有限的。這也引申了後面一句，後台還是要對每一個介面做驗權。
但是前端做許可權控制還是非常有意義的，我覺得在安全性方面來說，前端就顯示人體的皮膚，我們會是WEB安全的第一道防線。前端要做的工作，我認為有三種：
博客地址 北落師門
『伍』 前端如何控制用戶許可權
1. UI處理(根據用戶擁有的許可權,判斷頁面上的一些內容是否顯示)
2. 路由處理(當用戶訪問一個它沒有許可權訪問的url時,跳轉到一個錯誤提示的頁面)
3. HTTP請求處理(當我們發送一個數據請求,如果返回的status是401或者401,則通常重定向到一個錯誤提示的頁面)
如何實現?
首先需要在Angular啟動之前就獲取到當前用戶的所有的permissions,然後比較優雅的方式是通過一個service存放這個映射關系.對於UI處理一個頁面上的內容是否根據許可權進行顯示,我們應該通過一個directive來實現.當處理完這些,我們還需要在添加一個路由時額外為其添加一個"permission"屬性,並為其賦值表明擁有哪些許可權的角色可以跳轉這個URL,然後通過Angular監聽routeChangeStart事件來進行當前用戶是否擁有此URL訪問許可權的校驗.最後還需要一個HTTP攔截器監控當一個請求返回的status是401或者403時,跳轉頁面到一個錯誤提示頁面.
大致上的工作就是這些,看起來有些多,其實一個個來還是挺好處理的.
在Angular運行之前獲取到permission的映射關系
Angular項目通過ng-app啟動,但是一些情況下我們是希望Angular項目的啟動在我們的控制之中.比如現在這種情況下,我就希望能獲取到當前登錄用戶的所有permission映射關系後,再啟動Angular的App.幸運的是Angular本身提供了這種方式,也就是angular.bootstrap().看的仔細的人可能會注意到,這里使用的是$.get(),沒有錯用的是jQuery而不是Angular的$resource或者$http,因為在這個時候Angular還沒有啟動,它的function我們還無法使用.
進一步使用上面的代碼可以將獲取到的映射關系放入一個service作為全局變數來使用.
在取得當前用戶的許可權集合後,我們將這個集合存檔到對應的一個service中,然後又做了2件事:
(1) 將permissions存放到factory變數中,使之一直處於內存中,實現全局變數的作用,但卻沒有污染命名空間.
(2) 通過$broadcast廣播事件,當許可權發生變更的時候.
如何確定UI組件的依據許可權進行顯隱
這里我們需要自己編寫一個directive,它會依據許可權關系來進行顯示或者隱藏元素.
這里看到了比較理想的情況是通關一個has-permission屬性校驗permission的name,如果當前用戶有則顯示,沒有則隱藏.
擴展一下之前的factory:
路由上的依許可權訪問
這一部分的實現的思路是這樣: 當我們定義一個路由的時候增加一個permission的屬性,屬性的值就是有哪些許可權才能訪問當前url.然後通過routeChangeStart事件一直監聽url變化.每次變化url的時候,去校驗當前要跳轉的url是否符合條件,然後決定是跳轉成功還是跳轉到錯誤的提示頁面.
router.js:
mainController.js 或者 indexController.js (總之是父層Controller)
這里依然用到了之前寫的hasPermission,這些東西都是高度可復用的.這樣就搞定了,在每次view的route跳轉前,在父容器的Controller中判斷一些它到底有沒有跳轉的許可權即可.
HTTP請求處理
這個應該相對來說好處理一點,思想的思路也很簡單.因為Angular應用推薦的是RESTful風格的介面,所以對於HTTP協議的使用很清晰.對於請求返回的status code如果是401或者403則表示沒有許可權,就跳轉到對應的錯誤提示頁面即可.
當然我們不可能每個請求都去手動校驗轉發一次,所以肯定需要一個總的filter.代碼如下:
寫到這里我們就基本實現了在這種前後端分離模式下,前端部分的許可權管理和控制。
『陸』 前端許可權控制時要考慮的5個問題
1.登錄控制 哪些頁面不需要登錄就可以進入
實現思路： 在路由配置metal里配置是否需要登錄 默認需要登錄，在路由之前的鉤子里進行判斷
2.路由控制 不同角色訪問不同的頁面
實現思路：路由配置分成靜態路由和動態路由，動態路由部分按許可權返回的結果進行動態載入
3.頁面上的操作按鈕控制 不同的角色在同一個頁面 可以點擊的按鈕不同
寫一個命令進行操作控制
4.列表上增加刪除修改 控制 在獲取列表數據是返回顯示哪些按鈕
5.菜單顯示控制 根據不同的角色顯示不同的菜單
6.賬號切換時 重新載入對應路由
『柒』 Vue前端用戶許可權控制大全
用戶許可權是對特定資源的訪問許可，所謂許可權控制，也就是確保用戶只能訪問到被分配的資源
介面許可權目前一般採用通用的形式來驗證(用戶是否登錄系統)，沒有的話一般返回401，跳轉到登錄頁面重新進行登錄 ,
登錄成功後拿到token，將token存起來，通過axios請求攔截器進行攔截，每次請求的時候頭部攜帶token
通過自定義指令進行按鈕許可權的判斷
自定義許可權指令
在使用的按鈕中只需要引用v-has指令
全局路由守衛里做判斷
每次路由跳轉的時候都要判斷許可權，這里的判斷也很簡單，因為菜單的name與路由的name是一一對應的，而後端返回的菜單就已經是經過許可權過濾的
如果根據路由name找不到對應的菜單，就表示用戶有沒許可權訪問
如果路由很多，可以在應用初始化的時候，只掛載不需要許可權控制的路由。取得後端返回的菜單後，根據菜單與路由的對應關系，篩選出可訪問的路由，通過addRoutes動態掛載
這種方式的缺點：
菜單需要與路由做一一對應，前端添加了新功能，需要通過菜單管理功能添加新的菜單，如果菜單配置的不對會導致應用不能正常使用
全局路由守衛里，每次路由跳轉都要做判斷
『捌』 前端許可權控制
前端許可權控制分為四個方面的控制
第一點界面控制：用戶還未登入就能通過url訪問到系統頁面，該問題比較好解決通過路由守衛即可判斷。
如果用戶登入以後用url訪問不是屬於自己的菜單頁，如我沒有系統管理這個界面，我去地址欄輸入系統管理這個頁面的url，前端因該阻止它訪問頁面。輸入url能訪問到頁面的原因是你的路由配置了這個地址，所以控制界面的方式就是從路由入手，前期我們配置大家都有的路由，其他的路由根據登入系統時後台返回的許可權列表數據，動態添加路由。
在登入時我們把許可權數據存入vuex中並本地化，通過路由對象可以獲取到路由的配置，把那個用戶的路由單獨添加到路由列表中，使用addroutes添加更改後到路由配置，添加動態路由的方法調用在app.vue的created中，因為每次載入頁面都會調用該方法。
第二菜單控制:
根據用戶的不同菜單欄也不同，該問題跟動態路由類似登入時拿到數據存入vuex中並本地化，之後在菜單組件列表循環遍歷出對應的菜單欄，過於簡單就不截圖了。
第三按鈕控制：
這個控制可以採用自定義組件的方式，例如這個用戶沒有添加人員的按鈕，他只有查看這個人員菜單的許可權。在頁面上按鈕都添加上，但是是否能顯示則根據後端傳過來的許可權數據，該數據在動態路由作為meta數據添加在路由上了，也就是用路由的meta的數據去判斷這個按鈕是否顯示或者禁用或是可用，在頁面我們添加按鈕我們就加一個action屬於為add，我們或者add去比較如果沒有add這個許可權如果處理。上圖
第四請求攔截
請求攔截並不簡單的做一個token，而是每個用戶對應可以操作的請求放行，不是他可以操作的攔截，如他沒有添加的請求則要攔截，前面不是做了按鈕的控制嗎，為啥還要做這個攔截，按鈕控制並不安全，其實他可以通過瀏覽器直接修改按鈕的屬性，有人又說有token了不是可以攔截了嗎，對，可以攔截不過那時後台攔截，你請求還是發過去了，請求影響系統性能，所以做這個還是有必要的。
請求攔截，根據名字就知道他是在請求攔截器里設置的，在攔截器中可以獲取請求方式，根據請求方式與路由中的mate許可權對比有就發送請求，如果沒有則不發請求
『玖』 html怎麼在前端實現角色許可權控制
html在前端實現角色許可權控制操作：
1、框架提供了按鈕許可權的擴展服務，我們可以通過簡單的擴展來注冊我們自己的許可權項，我們通過繼承AbstractMenuPriv來實現我們的按鈕許可權類；
