A. Vue前端用戶許可權控制大全
用戶許可權是對特定資源的訪問許可，所謂許可權控制，也就是確保用戶只能訪問到被分配的資源
介面許可權目前一般採用通用的形式來驗證(用戶是否登錄系統)，沒有的話一般返回401，跳轉到登錄頁面重新進行登錄 ,
登錄成功後拿到token，將token存起來，通過axios請求攔截器進行攔截，每次請求的時候頭部攜帶token
通過自定義指令進行按鈕許可權的判斷
自定義許可權指令
在使用的按鈕中只需要引用v-has指令
全局路由守衛里做判斷
每次路由跳轉的時候都要判斷許可權，這里的判斷也很簡單，因為菜單的name與路由的name是一一對應的，而後端返回的菜單就已經是經過許可權過濾的
如果根據路由name找不到對應的菜單，就表示用戶有沒許可權訪問
如果路由很多，可以在應用初始化的時候，只掛載不需要許可權控制的路由。取得後端返回的菜單後，根據菜單與路由的對應關系，篩選出可訪問的路由，通過addRoutes動態掛載
這種方式的缺點：
菜單需要與路由做一一對應，前端添加了新功能，需要通過菜單管理功能添加新的菜單，如果菜單配置的不對會導致應用不能正常使用
全局路由守衛里，每次路由跳轉都要做判斷
B. 前端的許可權控制
1.菜單的控制
在登陸請求中，回到的許可權數據，這個許可權的數據是後端返回的數據，前端根據許可權數據，展示對應的菜單，點擊菜單，才能看到相關的界面。
2.界面的控制
如果用戶沒有登錄，手動在地址欄中輸入管理界面的地址，則頁面會跳轉到登錄界面，
如果用戶已經登錄，但是手動輸入非許可權內的地址，則會跳轉到404界面中去。
3.按鈕的控制
在某個菜單的界面中，還需要根據許可權數據，展示出該許可權范圍內可以操作的按鈕，比如增刪改查
4請求和相應的控制
如果用戶通過非常規的操作，比如通過瀏覽器的調試工具將某些禁用的按鈕變成了啟用的狀態，這個時候發的請求，也應該由前端所攔截。
C. 如何設置web頁面訪問許可權只允許登錄用戶訪問login.php，其他頁面未通過驗證均跳轉到登錄界面
在頁面最前面用session
這樣是對的
判斷的時候用
session_start();
if ($_SESSION['name'] == "admin") {
echo '登錄成功！';
} else {
//轉向登陸頁面
}
注銷時:
session_start();
$_SESSION = array();
if (isset($_COOKIE[session_name()])) {
setcookie(session_name(), '', time()-42000, '/');
}
session_destroy();
Session 對象存儲特定用戶會話所需的信息。這樣，當用戶在應用程序的 Web 頁之間跳轉時，存儲在 Session 對象中的變數將不會丟失，而是在整個用戶會話中一直存在下去。
cookie和session的功能是一樣的！
D. 前端如何控制用戶許可權
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.代碼如下:
寫到這里我們就基本實現了在這種前後端分離模式下,前端部分的許可權管理和控制。
E. 前端許可權控制-基於vue-router的動態路由實現
在中後台應用系統開發中，大部分情況下會涉及到用戶許可權控制，除了後端做許可權驗證外，前端在用戶訪問時也需要基於用戶許可權做相應控制。針對前端使用vue框架的情況，對頁面一級的許可權控制，常規處理是在頁面導航欄通過控制導航顯隱控制許可權，但在瀏覽器地址欄輸入訪問路徑依然可以訪問，可以用vue-router的動態路由來實現許可權控制。
登錄成功後通過addRoutes更新路由配置
正常情況下這樣就可以實現動態路由控制了，但刷新頁面發現會出現404，因為刷新時vue實例重新初始化了，導致動態路由被還原成默認路由，此時需要將許可權碼存儲在本地，在main.js中根據許可權碼重新生成動態路由
以上步驟基本可以實現動態添加路由並在刷新頁面是維持路由狀態，但訪問根路徑會始終跳轉到登錄頁，無法默認跳轉到首頁，這個問題目前還未想到好的解決方案。
F. html 怎麼在前端實現角色許可權控制
html在前端實現角色許可權控制操作：
1、框架提供了按鈕許可權的擴展服務，我們可以通過簡單的擴展來注冊我們自己的許可權項，我們通過繼承AbstractMenuPriv來實現我們的按鈕許可權類；
G. java 登錄時 的許可權 問題怎麼設置
在web應用中，對頁面的訪問控制通常通過程序來控制，流程為：
登錄 -> 設置session -> 訪問受限頁面時檢查session是否存在，如果不存在，禁止訪問
對於較小型的web應用，可以通過tomcat內置的訪問控制機制來實現許可權控制。採用這種機制的好處是，程序中無需進行許可權控制，完全通過對tomcat的配置即可完成訪問控制。
為了在tomcat頁面設置訪問許可權控制，在項目的WEB-INFO/web.xml文件中，進行如下設置：
Java代碼 復制代碼
1. <web-app>
2. <!--servlet等其他配置-->
3. <security-constraint>
4. <web-resource-collection>
5. <web-resource-name>My Test</web-resource-name>
6. <url-pattern>/admin/*</url-pattern>
7. </web-resource-collection>
8. <auth-constraint>
9. <role-name>role1</role-name>
10. <role-name>tomcat</role-name>
11. </auth-constraint>
12. </security-constraint>
13. <login-config>
14. <auth-method>BASIC</auth-method>
15. <realm-name>My Test</realm-name>
16. </login-config>
<web-app>
<!--servlet等其他配置-->
<security-constraint>
<web-resource-collection>
<web-resource-name>My Test</web-resource-name>
<url-pattern>/admin/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>role1</role-name>
<role-name>tomcat</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>My Test</realm-name>
</login-config>
其中，<url-pattern>中指定受限的url，可以使用通配符*，通常對整個目錄進行訪問許可權控制。
<auth-constraint>中指定哪些角色可以訪問<url-pattern>指定的url，在<role-name>中可以設置一個或多個角色名。
使用的角色名來自tomcat的配置文件$/conf/tomcat-users.xml。
<login-config>中設置登錄方式，<auth-method>的取值為BASIC或FORM。如果為BASIC，瀏覽器在需要登錄時彈出一個登錄窗口。如果為FORM方式，需要指定登錄頁面和登錄失敗時的提示信息顯示頁面。
使用FORM方式的配置樣例如下：
Java代碼 復制代碼
1. <login-config>
2. <auth-method>FORM</auth-method>
3. <realm-name>Example Form-Based Authentication Area</realm-name>
4. <form-login-config>
5. <form-login-page>/login.jsp</form-login-page>
6. <form-error-page>/error.jsp</form-error-page>
7. </form-login-config>
8. </login-config>
<login-config>
<auth-method>FORM</auth-method>
<realm-name>Example Form-Based Authentication Area</realm-name>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/error.jsp</form-error-page>
</form-login-config>
</login-config>
其中的<form-login-page>指定登錄頁面url，<form-error-page>指定登錄失敗時的提示頁面url。
登錄頁面中，form的action，以及其中的用戶名和密碼兩個參數的名稱，都應取固定的值。登錄的後台處理程序為j_security_check；用戶名和密碼的參數名稱分別為：j_username和j_password。
如下是登錄頁面（如：login.jsp）的一段示例代碼：
Java代碼 復制代碼
1. <form method="POST" action='<%= response.encodeURL("j_security_check") %>' >
2. <table border="0" cellspacing="5">
3. <tr>
4. <th align="right">Username:</th>
5. <td align="left"><input type="text" name="j_username"></td>
6. </tr>
7. <tr>
8. <th align="right">Password:</th>
9. <td align="left"><input type="password" name="j_password"></td>
10. </tr>
11. <tr>
12. <td align="right"><input type="submit" value="Log In"></td>
13. <td align="left"><input type="reset"></td>
14. </tr>
15. </table></form>
H. 許可權管理（React）
公司需要做一款產品，裡面需要有一個平台用來類似手機APP似的房子不同的子產品入口（類快捷圖標），各子產品間實現單點登錄，創建不同賬戶級別，可以分配產品許可權，產品資源許可權，產品操作級許可權。
本產品，最後許可權做了雙重控制，前後端都控制， 本文只從前端角度進行總結。
賬戶所擁有的產品許可權信息，登錄後後台將會返回數組形式，每項包含一些信息，至於這些產品信息管理，也在後台系統中進行統一管理配置，之後將會在資源許可權提及。
其中，主要是url來進行跳轉，這里有個問題：url里的路徑有時是同一域名下的產品，也可以是一些以前的產品路徑，這就需要進行url判斷
當然，有人會問，如果直接進入一個產品地址，如何判斷登錄呢？
我們前後端約定好一個未登錄code碼 401
其實前端也將登錄後的用戶信息存入了localstorage, 退出登錄後將會銷毀，這也能進行登錄驗證，但是不是很准確；當然這里其實還得進行路由許可權驗證，這下面將會講到。
路由許可權設計有些考慮的問題：
後台系統資源管理設計
資源管理採用樹形結構，同級葉子可以進行拖拽調換位置展示導航菜單，每級葉子均可以添加葉子，刪除修改。葉子的信息這里有些特有的設計：
登錄後，對顯示菜單進行渲染後，要對訪問的路由進行訪問許可權審核檢查：
操作許可權管理界面
操作許可權主要是設計了一個webkey配置，方便前端的操作許可權的檢測。操作許可權是進行統一管理的，路徑資源管理下可以進行操作許可權的勾選配置。
操作許可權由於涉及到按鈕級，也就是組件級，不能在每個頁面單獨配置，那樣需求改動，將會陷入深坑。我採用的 HOC 高階組件的封裝套路：
界面中使用也是很簡單：
這樣採用HOC進行封裝，可以進行一些別的需要擴展：加入操作動畫，改變樣式等。
不同的用戶登錄以後，對數據范圍的許可權是有限制的，那些能夠訪問，那些不能訪問在產品設計的是就已經定義好，當訪問一個當前登錄用戶無權訪問的 API 或者數據的時候，API 響應中會返回對應的 code, 這個 code 是提前就前後的約定好的值。
這部分許可權需要在 xhr api 層調用介面時進行數據許可權的判斷
總結一下，其實前端在做許可權控制的時候，依賴於後端 API 返回的配置信息，所以在許可權設計，路由設計，數據結構設計的時候，前後端一定要約定好。