Ⅰ 許可權管理（React）
公司需要做一款產品，裡面需要有一個平台用來類似手機APP似的房子不同的子產品入口（類快捷圖標），各子產品間實現單點登錄，創建不同賬戶級別，可以分配產品許可權，產品資源許可權，產品操作級許可權。
本產品，最後許可權做了雙重控制，前後端都控制， 本文只從前端角度進行總結。
賬戶所擁有的產品許可權信息，登錄後後台將會返回數組形式，每項包含一些信息，至於這些產品信息管理，也在後台系統中進行統一管理配置，之後將會在資源許可權提及。
其中，主要是url來進行跳轉，這里有個問題：url里的路徑有時是同一域名下的產品，也可以是一些以前的產品路徑，這就需要進行url判斷
當然，有人會問，如果直接進入一個產品地址，如何判斷登錄呢？
我們前後端約定好一個未登錄code碼 401
其實前端也將登錄後的用戶信息存入了localstorage, 退出登錄後將會銷毀，這也能進行登錄驗證，但是不是很准確；當然這里其實還得進行路由許可權驗證，這下面將會講到。
路由許可權設計有些考慮的問題：
後台系統資源管理設計
資源管理採用樹形結構，同級葉子可以進行拖拽調換位置展示導航菜單，每級葉子均可以添加葉子，刪除修改。葉子的信息這里有些特有的設計：
登錄後，對顯示菜單進行渲染後，要對訪問的路由進行訪問許可權審核檢查：
操作許可權管理界面
操作許可權主要是設計了一個webkey配置，方便前端的操作許可權的檢測。操作許可權是進行統一管理的，路徑資源管理下可以進行操作許可權的勾選配置。
操作許可權由於涉及到按鈕級，也就是組件級，不能在每個頁面單獨配置，那樣需求改動，將會陷入深坑。我採用的 HOC 高階組件的封裝套路：
界面中使用也是很簡單：
這樣採用HOC進行封裝，可以進行一些別的需要擴展：加入操作動畫，改變樣式等。
不同的用戶登錄以後，對數據范圍的許可權是有限制的，那些能夠訪問，那些不能訪問在產品設計的是就已經定義好，當訪問一個當前登錄用戶無權訪問的 API 或者數據的時候，API 響應中會返回對應的 code, 這個 code 是提前就前後的約定好的值。
這部分許可權需要在 xhr api 層調用介面時進行數據許可權的判斷
總結一下，其實前端在做許可權控制的時候，依賴於後端 API 返回的配置信息，所以在許可權設計，路由設計，數據結構設計的時候，前後端一定要約定好。
Ⅱ Vue前端用戶許可權控制大全
用戶許可權是對特定資源的訪問許可，所謂許可權控制，也就是確保用戶只能訪問到被分配的資源
介面許可權目前一般採用通用的形式來驗證(用戶是否登錄系統)，沒有的話一般返回401，跳轉到登錄頁面重新進行登錄 ,
登錄成功後拿到token，將token存起來，通過axios請求攔截器進行攔截，每次請求的時候頭部攜帶token
通過自定義指令進行按鈕許可權的判斷
自定義許可權指令
在使用的按鈕中只需要引用v-has指令
全局路由守衛里做判斷
每次路由跳轉的時候都要判斷許可權，這里的判斷也很簡單，因為菜單的name與路由的name是一一對應的，而後端返回的菜單就已經是經過許可權過濾的
如果根據路由name找不到對應的菜單，就表示用戶有沒許可權訪問
如果路由很多，可以在應用初始化的時候，只掛載不需要許可權控制的路由。取得後端返回的菜單後，根據菜單與路由的對應關系，篩選出可訪問的路由，通過addRoutes動態掛載
這種方式的缺點：
菜單需要與路由做一一對應，前端添加了新功能，需要通過菜單管理功能添加新的菜單，如果菜單配置的不對會導致應用不能正常使用
全局路由守衛里，每次路由跳轉都要做判斷
Ⅲ html 怎麼在前端實現角色許可權控制
html在前端實現角色許可權控制操作：
1、框架提供了按鈕許可權的擴展服務，我們可以通過簡單的擴展來注冊我們自己的許可權項，我們通過繼承AbstractMenuPriv來實現我們的按鈕許可權類；
Ⅳ 前端如何控制用戶許可權
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.代碼如下:
寫到這里我們就基本實現了在這種前後端分離模式下,前端部分的許可權管理和控制。
Ⅳ 前端如何實現登錄攔截
如一個購物商城, 當你瀏覽某個商品需要購買時, 點擊 購買按鈕 這時需要檢測是否登錄。
如果用戶已經登錄，則進入購買頁,否則進入登錄頁面。
如一個後台管理系統, 如果不登錄則不能訪問任何頁面。
有兩種攔截方式 路由攔截 和 http攔截器
一、路由攔截
首先在定義路由的時候就需要多添加一個自定義欄位 requireAuth，用於判斷該路由的訪問是否需要登錄。如果用戶已經登錄，則順利進入路由， 否則就進入登錄頁面。
定義完路由後，利用 vue-router 提供的鉤子函數 beforeEach() 對路由進行判斷。
每個鉤子方法接收三個參數：
to : ( Route ) 即將要進入的目標 路由對象
from : ( Route ) 當前導航正要離開的路由
next : ( Function ) 一定要調用該方法來 resolve 這個鉤子。執行效果依賴 next 方法的調用參數。
next() : 進行管道中的下一個鉤子。如果全部鉤子執行完了，則導航的狀態就是 confirmed （確認的）。
next(false) : 中斷當前的導航。如果瀏覽器的 URL 改變了（可能是用戶手動或者瀏覽器後退按鈕），那麼 URL 地址會重置到 from 路由對應的地址。
next(『/』) 或者 next({ path: 『/』 }) : 跳轉到一個不同的地址。當前的導航被中斷，然後進行一個新的導航。
確保要調用 next 方法，否則鉤子就不會被 resolved。
to.meta 中是我們自定義的數據，其中就包括我們剛剛定義的 requireAuth 欄位。通過這個欄位來判斷該路由是否需要登錄許可權。需要的話，同時當前應用不存在token，則跳轉到登錄頁面，進行登錄。登錄成功後跳轉到目標路由。
二、http攔截器
路由攔截只是簡單的前端路由控制，並不能真正阻止用戶訪問需要登錄許可權的路由。還有一種情況便是：當前token失效了，但是token依然保存在本地。這時候你去訪問需要登錄許可權的路由時，實際上應該讓用戶重新登錄。
這時候就需要結合 http 攔截器 + 後端介面返回的http 狀態碼來判斷。
axios 的攔截器可通過配置http response inteceptor，當後端介面返回401 Unauthorized（未授權），讓用戶重新登錄。
如有不妥歡迎留言, 希望能幫助到你~
Ⅵ 請教XX管理系統的前端頁面展示和後端許可權控制的一般解決方案
前端面向的是用戶編程，就是用戶可以看得到摸得到的。UI就是其中的一部分。後端是面向服務(伺服器)編程，用戶是無須知道裡面的操作的。舉個例子。比如簡單的登陸功能。前端的只要做好兩個文本控制項與一個按鈕控制項，並且監聽按鈕的點擊事件，將兩個文本的參數按照協議發送到伺服器端上。這就是前端要做的。而後端，伺服器就要接收發送過來的消息並且調用資料庫驗證用戶名與密碼。成功後返回結果。
Ⅶ 菜單許可權是對前端菜單的許可權嗎
對的，用戶菜單里的才是該用戶真正有許可權使用的事務代碼。SAP標准菜單是針對所有人一樣的，不是每個事務
Ⅷ 前端許可權控制
前端許可權控制分為四個方面的控制
第一點界面控制：用戶還未登入就能通過url訪問到系統頁面，該問題比較好解決通過路由守衛即可判斷。
如果用戶登入以後用url訪問不是屬於自己的菜單頁，如我沒有系統管理這個界面，我去地址欄輸入系統管理這個頁面的url，前端因該阻止它訪問頁面。輸入url能訪問到頁面的原因是你的路由配置了這個地址，所以控制界面的方式就是從路由入手，前期我們配置大家都有的路由，其他的路由根據登入系統時後台返回的許可權列表數據，動態添加路由。
在登入時我們把許可權數據存入vuex中並本地化，通過路由對象可以獲取到路由的配置，把那個用戶的路由單獨添加到路由列表中，使用addroutes添加更改後到路由配置，添加動態路由的方法調用在app.vue的created中，因為每次載入頁面都會調用該方法。
第二菜單控制:
根據用戶的不同菜單欄也不同，該問題跟動態路由類似登入時拿到數據存入vuex中並本地化，之後在菜單組件列表循環遍歷出對應的菜單欄，過於簡單就不截圖了。
第三按鈕控制：
這個控制可以採用自定義組件的方式，例如這個用戶沒有添加人員的按鈕，他只有查看這個人員菜單的許可權。在頁面上按鈕都添加上，但是是否能顯示則根據後端傳過來的許可權數據，該數據在動態路由作為meta數據添加在路由上了，也就是用路由的meta的數據去判斷這個按鈕是否顯示或者禁用或是可用，在頁面我們添加按鈕我們就加一個action屬於為add，我們或者add去比較如果沒有add這個許可權如果處理。上圖
第四請求攔截
請求攔截並不簡單的做一個token，而是每個用戶對應可以操作的請求放行，不是他可以操作的攔截，如他沒有添加的請求則要攔截，前面不是做了按鈕的控制嗎，為啥還要做這個攔截，按鈕控制並不安全，其實他可以通過瀏覽器直接修改按鈕的屬性，有人又說有token了不是可以攔截了嗎，對，可以攔截不過那時後台攔截，你請求還是發過去了，請求影響系統性能，所以做這個還是有必要的。
請求攔截，根據名字就知道他是在請求攔截器里設置的，在攔截器中可以獲取請求方式，根據請求方式與路由中的mate許可權對比有就發送請求，如果沒有則不發請求
Ⅸ 前端許可權控制時要考慮的5個問題
1.登錄控制 哪些頁面不需要登錄就可以進入
實現思路： 在路由配置metal里配置是否需要登錄 默認需要登錄，在路由之前的鉤子里進行判斷
2.路由控制 不同角色訪問不同的頁面
實現思路：路由配置分成靜態路由和動態路由，動態路由部分按許可權返回的結果進行動態載入
3.頁面上的操作按鈕控制 不同的角色在同一個頁面 可以點擊的按鈕不同
寫一個命令進行操作控制
4.列表上增加刪除修改 控制 在獲取列表數據是返回顯示哪些按鈕
5.菜單顯示控制 根據不同的角色顯示不同的菜單
6.賬號切換時 重新載入對應路由
Ⅹ shiro前端多角色的許可權怎麼寫
一兩句話說不清楚，我推薦一套完整已經實現了你說的功能的項目給你。
Shiro介紹文檔：http://www.sojson.com/shiro
Demo已經部署到線上，地址是http://shiro.itboy.net，
管理員帳號：admin，密碼：sojson.com 如果密碼錯誤，請用sojson。
PS：你可以注冊自己的帳號，然後用管理員賦許可權給你自己的帳號，但是，每20分鍾會把數據初始化一次。建議自己下載源碼，讓Demo跑起來，然後跑的更快。