業務場景

• 許可權管理類的網站會存在一個定製化的業務需求，不同的使用者擁有不同的功能介面、不同的業務許可權.從專案角度來描述就是不同的使用者擁有不同的角色，不同的角色綁定了不同的功能模組，並且要保證使用者不能操作許可權之外的功能。基於這樣的出發點可以考慮建立一套多使用者、多角色、多種功能、使用者<–>角色<–>選單靈活繫結的程式。
• 這種需求名為‘基於角色的許可權訪問控制’（Role-Based Access Control），簡稱為RBAC。RBAC支援三個著名的安全原則：最小許可權原則，責任分離原則和資料抽象原則。在RBAC中，許可權與角色相關聯，使用者通過成為適當角色的成員而得到這些角色的許可權。這就極大地簡化了許可權的管理。在一個組織中，角色是為了完成各種工作而創造，使用者則依據它的責任和資格來被指派相應的角色，使用者可以很容易地從一個角色被指派到另一個角色。角色可依新的需求和系統的合併而賦予新的許可權，而許可權也可根據需要而從某角色中回收。角色與角色的關係可以建立起來以囊括更廣泛的客觀情況。
• 想要做到從使用者到功能的精確控制，要從資料庫表結構設計和程式碼控制同時進行。資料庫表的設計包含使用者表、使用者角色表、選單表、使用者角色關聯表、角色選單關聯表等表的欄位及關聯關係。程式碼中需要使用的攔截器對訪問的連結進行許可權驗證、根據使用者動態載入介面、頁面展示需要使用z-tree外掛。
  表設計
• user:使用者表用於存放使用者基礎資料
  
• role：角色表使用者存放角色名稱
  
• user-role：使用者角色表，存放使用者表id河角色表id，一個使用者id可能會對應多個角色id，如果使用資料量很大，建議對兩個id欄位做索引
  
• menu：選單表使用者存放所有功能選單，包含選單名稱、連結、標籤、父級id、選單等級等資料，因為選單資料要在許可權設定時做展示，所以資料要設計為輸結構，方便載入和篩選
  
• role-menu：角色選單表使用者存放角色id和選單id的關聯關係，同樣一個角色id可能會對應多個選單id，資料量大的情況下建議對兩個id欄位做索引
  

資料錄入

後臺介面可以使用easyui，介面效果如下，為了演示我去掉了授權功能，實際情況還有一個使用者、角色、選單的授權功能。使用者在登入時驗證了使用者名稱和密碼準確無誤後，通過使用者的id去user-role表查到使用者擁有的所有角色並找到使用者擁有的所有選單，頁面載入時使用el表示式解析所有選單，動態呈現出介面效果。

選單在資料庫儲存如下：

menu_href欄位用作攔截器鑑權，button_htmlcontent欄位是頁面的標籤用作後臺載入，button_htmlcontent詳細內容為：

`<a href="javascript:void(0)" onclick="jump("<%=rootPath%>admin/store/getStoresByStoreState.do?storeState=1")">模組1</a>`

後臺的授權模組分為使用者、角色、選單三個二級模組

使用者模組包含使用者的增、改、查，新增使用者時可以選擇對應的角色：

角色模組中包含了角色的新增和修改，其中角色對選單的控制要使用z-tree對資料的樹狀展示，通過勾選繫結選單

選單模組中包含了對選單資料的修改、檢視的操作，左側的選單資料也是一顆z-tree樹，

攔截與鑑權

• 使用者登入後相應的獲取使用者id找到角色和選單，並且按照標籤的格式在頁面展示出來。許可權鑑定要使用到攔截器，每次獲取操作的url，如果使用者有此選單的許可權即可正常操作，反之提醒操作失敗。
• 對於三級選單上詳細操作的鑑權有兩種方案，第一種是將每個三級選單上所有操作的url都和選單一樣錄入資料庫，使用者在操作的時候從資料庫查詢並鑑權。這麼做可以詳細的控制到使用者對某個功能的增、刪、改、查許可權。第二種方案是每個功能的下的url命名和選單url命名保持前段相同，假如存在某個使用者選單的url為"admin/user/userList.do",這個選單下的新增使用者功能url為"admin/user/userAdd.do"。想要操作新增使用者的功能，必須有"admin/user/"開頭的三級選單許可權，否則操作越權。