許可權系統真的很難實現嗎？–開源軟體誕生11
【赤龍ERP】許可權系統的那些事–第11篇
用日誌記錄「開源軟體」的誕生
部落客的開源空間：進入地址，點亮星標
【您的鼓勵，我的動力，一個老程式設計師的心聲】
前言
幾乎每家公司的管理系統里都存在許可權系統的身影，而且實現方式多種多樣，配置流程千奇百怪。甚至在一家公司里見到過幾百頁的許可權系統需求文檔。許可權系統實現起來很困難嗎？我不置可否，下面就來一起抽絲剝繭。
許可權系統應該解決什麼事
許可權系統乍聽起來好像很深奧，其實可以很簡單：它是一個管理誰有權看哪些內容、做哪些事的系統。好吧，貌似我一句話說完了，其實本節可以結束了。如果覺得我解釋得太少的同學，我再多說兩句。
（1）任何應用系統中的功能，絕對不是任何人都可以無限制使用的，我們一定是想做一些控制，來實現拆分、隔離、安全、高效等多方面的管控。許可權系統應運而生。
（2）要控制的對象是人。所以許可權系統必選先管人，我們通常叫做賬戶，一個人一個賬戶。而人又不是獨立存在的，人存在於組織里，所以我們也要管組織。
（3）人要做的是事。我們關心的是，一個人可以看哪些，做哪些，甚至是看到哪些數據。緊接著就是我們如何將事分類，並最終賦給人身上。
需要注意的是：許可權系統只需關心上面的內容，至於如何將許可權集成應用，以及更加業務化的問題，完全不必要進行考慮。
許可權系統的實現方式有哪些
說到實現方式，我見過複雜的，也見過極簡的，下面從模組的角度列舉一下。
一、極簡版：用戶與許可權。
這種方式開發起來簡單，但配置起來極其複雜，也會出現很多意想不到的問題和風險。
二、通用版：用戶、角色、許可權。
這種方式應該是我們最常見到的，中間加了角色一層，解決了配置複雜度的問題。【赤龍ERP】就是這個版本進行優化而來。
三、高級版：用戶、職責、許可權、菜單、工具欄、可執行
這種方式是我遇到的比較科學的設計方式，幾乎可以說是涵蓋了所有常見的需要許可權管理的內容，優點當然是靈活，但也極大增加了開發成本和管理成本。
四、其他：用戶、用戶組、角色、許可權、菜單
這種方式可以理解成通用版的一個進化版本，更多的考慮的是配置的靈活度，也不像高級版那麼複雜，筆者之前企業中用的這種方式，總結一下，這種設計思路是好的，但在實踐中貌似多慮了。
我如何實現許可權控制
下面就在具體講述一下，我在【赤龍ERP】中的許可權系統是如何實現的。
（1）用戶管理：在這裡我只管理賬戶和密碼，不管理其他任何用戶的資訊和職員的資訊。不把登陸帳號和其他用戶數據做強耦合，這樣可以更加靈活的管理用戶。
（2）角色管理：角色是一組許可權的集合，但絕不是無場景的組合。角色一定是從業務角度出發的一類職責所涉及到的許可權的匯總。
（3）許可權管理：首先是對許可權的分類，即上面提到的對”事”的分類。常見的三類是：菜單許可權、操作許可權和數據許可權。其次也是最重要的叫做約定。開發上有一個思路叫約定大於配置。我們現在要做的就是如何通過約定許可權命名的方式，來實現無特殊配置和編程的許可權控制。也就是說，我們並不通過配置和編碼的方式來實現：誰能看到哪些菜單，誰能操作哪些功能、誰能看到哪些數據，而是約定一系列規則，通過規則來判斷擁有哪些許可權的人可以做哪些事情，那麼在符合規則的前提下，我們只需要命名我們需要的許可權即可。
特殊說明：這也就是為什麼在我的許可權系統設計時並不需要高級版的那些菜單管理、工具欄管理、可執行管理等功能
（4）關聯關係：用戶與角色、角色與許可權。首先關聯一定是多對多。最終的目的是找到用戶有哪些角色，用戶有哪些許可權；因為最終請求的攔截一般都是通過角色和許可權完成的。但設計時一定要避免過多的關聯重複，以及考慮到許可權範圍大小的設置問題。
後記
由此看見，許可權系統本身並不複雜，複雜的是如何用最簡單的功能實現更多的管控。也就是上面我所說的約定規則的制定。在此不展開篇章講解。如果大家感興趣，可以進入【赤龍ERP】找到答案。
