用戶權限管理

用戶及權限管理涉及的幾個概念

用戶分類：系統用戶、超級用戶、管理員用戶、DBA用戶、領導用戶、專家用戶、操作員用戶、客戶用戶、……
系統權限：即對不同用戶使用系統資源（功能菜單項、按鈕、輸入控件等）的使用或訪問權限
用戶：應用系統的具體操作者，用戶可以擁有一定範圍的權限
角色：爲了對許多擁有相似權限的用戶進行分類管理，定義了角色的概念，例如系統管理員、管理員、用戶、訪客等角色
組：爲了更好地管理用戶，對用戶進行分組歸類，簡稱爲用戶分組，如普通QQ羣、高級QQ羣；一級單位用戶、二級單位用戶等

權限、用戶、角色、組之間的關係

用戶的權限集 ＝ 自身的權限 ＋ 所屬的各角色權限 ＋ 所屬的各組權限

用戶及權限管理設計方案

1. 基於角色的權限設計

最常見也是比較簡單的方案，通常這種設計已經足夠。

2. 基於操作的權限設計

該模式下每一個“操作”都在數據庫中有記錄，用戶是否擁有該操作的權限也在數據庫中有記錄
問題：如果直接使用上面的設計，會導致數據庫中的UserAction表數據量非常大，需要進一步設計提高效率。

3. 基於角色和操作的權限設計

該方案是對方案2的改進：添加了Role和RoleAction表，從而可以減少UserAction中的記錄，並且使設計更靈活
不足：經常需要定義新的“角色” 例如：當用戶要求臨時給某位普通員工某操作權限時，就需要新增加一種新的用戶角色，但是這種用戶角色是不必要的，因爲它只是一種臨時的角色，如果添加一種角色還需要在收回此普通員工權限時刪除此角色

4. 精確至數據記錄的權限設計

該方案需要對每一種不同的資源創建一張權限表
例如：上圖中對Content和Channel兩種資源分別創建了UserActionContent和UserActionChannel表用來定義用戶對某條記錄是否有權限。

優點：比較靈活，可以對設置各種權限，對於不同的資源可以有自己的一套方案。

不足：該設計可以滿足用戶需求但是不是很經濟，UserActionChannel和UserActionContent中的記錄會很多，而在實際的應用中並非需要記錄所有的記錄的權限信息，有時候可能只是一種規則，比如說對於跟Channel什麼級別的人有權限，這時我們就可以定義些規則來判斷用戶權限。

權限、用戶、角色、組之間的關係