RCBA

       許可權：權利(能做的)和限制(不能做的)，在許可權範圍內做好自己的事情，不該看的不看(機密)，不該做的不做！最開始真正有許可權的概念是在Linux上關於檔案和目錄的許可權，再後來聯想到在Windows系統下對某些系統檔案的操作，慢慢回想起以前所遇到的關於許可權的事情！許可權管理，平時裡很多地方我們都可以看到，比如聊QQ時群裡的群主、管理員以及成員之間的功能是不一樣的……大家一定會遇到的一個問題，所以整理 一下自己寫許可權系統的一些經驗給大家，只起參考作用。

       RCBA

：基於角色的許可權訪問控制(Role-Based Access Control)

一、為什麼要實現許可權系統

1、 系統中的許可權系統，缺少組織結構管理。例如：樹型的組織結構，有些系統雖然考慮了分層，但是沒有考慮分多少層，組織結構是否考慮了集團公司，全國連鎖經營這種模式，實際上就是很多個獨立單位的概念。很多系統遇到這個問題，就需要重新做整個系統。
2、 不同登陸使用者要有不同的權利，而且要有不同的選單，如果不能靈活的修改他們的許可權，那使用者需求一旦變化，不是就很鬱悶了。系統要能夠解決這個問題，我們就要靈活的控制每個頁面。即便是系統已經開發完成，投入執行，也可以通過修改配置檔案，而實現許可權的重新調整。

二、許可權簡單控制原理

規則一：每個登陸的使用者，可以有多個角色；
規則二：每個角色又可以訪問多個功能點；
規則三：每個功能點又由多個頁面組成；
根據這個對應關係，就可以讓每個使用者對應到不同的頁面，如果進行細緻設定，基本上可以解決了應用中的很多情況

三、名詞解釋

       頁面(URL)：在web開發中也稱為URL，最樸素的許可權控制，就是基於頁面的控制,即賦予訪問者可以訪問頁面的範圍，在系統記錄所有的頁面，配置許可權時將允許訪問的頁面賦予使用者。雖然簡單,卻很直接和容易理解，基於這個思想，將軟體的URL作為許可權,進行控制，將所有的URL進行記錄。但如果直接將URL作為許可權配置給使用者,是相當麻煩的，因為一個操作功能往往不是在一個請求內完成的，這就意味著為了讓使用者有權利完成一個功能，就必須將一組URL賦予使用者，以便其訪問，顯然這樣給系統管理和維護帶來了很多不方便.因此我們就需要功能點

。

      功能點: 是一組不可分割URL(url的集合)，因為這組URL共同完成一個功能，因此他們是不可分開的。使用者要正常完成操作,就必須有權訪問這組URL中的每一個，這樣將一個功能點賦予使用者，也就意味著這個使用者有訪問這些URL的能力。在業務中系統管理員不用關心到底什麼許可權對應哪些URL，只要將功能點賦予使用者，就可以關聯URL了，完成授權過程。

      角色: 角色又可以成為"崗位",它是一組功能點。很多時候多個使用者的操作許可權是相同的，例如一個部門中，大家都有察看自己郵箱的權利，都有修改自己口令和基本資訊的權利。這時,就將郵箱功能點、修改口令、基本資訊維護這幾個功能點集合起來,建立一個色--"操作員崗"。那麼在給使用者授權時，只要將這個角色賦予使用者，該使用者就擁有了相應的功能操作許可權。適合多使用者許可權的管理，尤其是使用者數量眾多而且許可權相同或者類似時，可以減少很多麻煩，減少出錯概率。同時一個使用者可以同時擁有多個角色，這些角色所代表的許可權,使用者可以同時擁有,是許可權的並集。例如一個部門經理可以有"操作員"角色，具備基本的操作許可權，同時還可以將"部門稽核員"這個角色授予他，這樣可以作操作部分管理功能。這樣做可以靈活的組合和配置使用者許可權，適應複雜許可權管理。

      使用者:是軟體系統使用者的系統賬號。每個使用者都有自己獨一無二的賬號，系統通過這個賬號來識別不同的使用者。賬號的安全是通過使用者口令加以保護的，口令在系統中是用加密的方式進行儲存，避免了通過資料庫系統洩漏使用者口令的問題。系統使用者是通過"使用者"與"功能點"關聯，完成使用者的授權，在使用者登陸系統後，也是通過"使用者"來認證當前使用者的許可權。

 說明：將許可權和角色關聯起來，就可以把許可權和使用者的耦合解開，然後將角色和使用者關聯從而來達到使用者和許可權的最終關聯！

圖1------>三權分立，最終關聯！

四、資料庫設計

       一個使用者可以擁有多個許可權，同時一個許可權也可以賦予多個使用者，那麼使用者和許可權就是多對多的關係，那麼就需要角色表來維護和連結使用者和許可權的關係。通過使用者和角色關聯，角色和許可權關聯，從而實現使用者和許可權的一個間接關係。那麼問題又來了，使用者和角色也是多對多的關係，角色和許可權也是多對多的關係，我們還需要兩張中間表，就是使用者角色表和角色許可權表。
1、使用者表：登入的使用者
2、角色表：與許可權相關聯
3、許可權表：與角色相關聯------>功能，具體的可操作的選單項
4、使用者角色表：使用者和角色的中間表
5、角色功能表：角色和功能的中間表

圖1---表的設計

互動過程：一個使用者登陸了，先去找角色關聯起來，再去找這些角色關聯了什麼樣的操作，最後把這些操作對應給使用者，那麼使用者一登入所看到的的就是可以操作的，也就是他許可權範圍內可以做的事情！

補充：Java許可權管理之許可權型別！

(1)特點：看到什麼就操作什麼！簡單粗暴！

(3)特點：選單就類似於導航，而功能就是對應的增刪該查！

(4)特點：企業內部有很多系統，ERP、EHR、OA、CRM等等！怎麼去管理？--->瞭解各系統名詞的含義！

傳統就是每個系統都有一個賬號，登入還得切換！現在一個使用者一個密碼，對應所有的企業內部的系統，所謂的SSO單點登入！

好處：方便管理和操作！

#####################################分割線#########################################

五、許可權的設計與實現

(1)表中特殊的設計

特別說明：

時間--->插入和修改的時間！

使用者狀態-->有效和無效！

(2)程式碼中實體(POJO類)的設計

(2)包的設計

說明：dto是資料傳輸物件的縮寫，由於資料是在controller和頁面之間進行傳輸，有些頁面涉及多個實體的資料同時展示，用dto進行封裝。

Tree：導航的樹形結構

資料快取：比如把整個選單快取起來。每次登陸展示就特別方便！

使用者資訊：超時時間、許可權資訊等

(4)包的最終結構

說明：AjaxResult

(5)許可權和應用程式

說明：方式2根據編碼-->Apach開源的的shiro和更復雜的Spring Security來實現許可權控制！

(6)兩種細說

說明：重點掌握！

1、使用者,角色,許可權(功能),角色許可權,使用者角色五個實體類對應五張表(省略...)
2、action層呼叫service層，service層呼叫dao層
action是介面層：管理業務（service）排程和管理跳轉的，是一個管理器，只負責管理
service是業務邏輯層：管理具體功能和邏輯的，負責實施--->巨集觀！
DAO資料訪問層：只完成增刪改查，只負責封裝，具體的業務邏輯如何去實現由service實施-->微觀！
3、action：實現頁面的功能
service：先定義一個介面抽象出具有的功能，再由impl去具體的實現，dao也是如此。

六、原始碼

在寫許可權管理的時候最頭痛的地方也就是許可權功能的模組了，但是不管是怎樣的一個業務也是資料的增刪改

原始碼省略。。。

七、總結

以上只是功能模組的程式碼，還有角色、使用者、使用者角色。角色許可權等模組，這些也就僅僅是資料的增刪改查操作，只要大家用心的去寫一下就可以了。不管是怎樣的許可權管理系統遠遠要比這個複雜，這裡只是為了給大家提供功能模組的思維，僅供大家參考。