權限管理設計一

我們在開發系統的時候，經常會遇到系統需要權限控制，而權限的控制程度不同有不同的設計方案。

1.       基于角色的權限設計

這種方案是最常見也是比較簡單的方案，不過通常有這種設計已經夠了，是以微軟就設計出這種方案的通用做法，這種方案對于每一個操作不做控制，隻是在程式中根據角色對是否具有操作的權限進行控制；這裡我們就不做詳述

2.       基于操作的權限設計

這種模式下每一個操作都在資料庫中有記錄，使用者是否擁有該操作的權限也在資料庫中有記錄，結構如下：

但是如果直接使用上面的設計，會導緻資料庫中的UserAction這張表資料量非常大，是以我們需要進一步設計提高效率，請看方案3

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

如上圖所示，我們在添加了Role，和RoleAction表，這樣子就可以減少UserAction中的記錄，并且使設計更靈活一點。

但是這種方案在使用者需求的考驗之下也可能顯得不夠靈活夠用，例如當使用者要求臨時給某位普通員工某操作權限時，我們就需要新增加一種新的使用者角色，但是這種使用者角色是不必要的，因為它隻是一種臨時的角色，如果添加一種角色還需要在收回此普通員工權限時删除此角色，我們需要設計一種更合适的結構來滿足使用者對權限設定的要求。

4.       2,3組合的權限設計，其結構如下：

我們可以看到在上圖中添加了UserAction表，使用此表來添加特殊使用者的權限，改表中有一個字段HasPermission可以決定使用者是否有某種操作的權限，改表中記錄的權限的優先級要高于UserRole中記錄的使用者權限。這樣在應用程式中我們就需要通過UserRole和UserAction兩張表中的記錄判斷權限。

到這兒呢并不算完，有可能使用者還會給出這樣的需求：對于某一種action所操作的對象某一些記錄會有權限，而對于其他的記錄沒有權限，比如說一個内容管理系統，對于某一些頻道某個使用者有修改的權限，而對于另外一些頻道沒有修改的權限，這時候我們需要設計更複雜的權限機制。

5.       對于同一種實體（資源）使用者可以對一部分記錄有權限，而對于另外一些記錄沒有權限的權限設計：

對于這樣的需求我們就需要對每一種不同的資源建立一張權限表，在上圖中對Content和Channel兩種資源分别建立了UserActionContent和UserActionChannel表用來定義使用者對某條記錄是否有權限；這種設計是可以滿足使用者需求的但是不是很經濟，UserActionChannel和UserActionContent中的記錄會很多，而在實際的應用中并非需要記錄所有的記錄的權限資訊，有時候可能隻是一種規則，比如說對于根Channel什麼級别的人有權限；這時候呢我們就可以定義些規則來判斷使用者權限，下面就是這種設計。

6.       涉及資源，權限和規則的權限設計

在這種設計下角色的概念已經沒有了，隻需要Rule在程式中的類中定義使用者是否有操作某種對象的權限。

以上隻是分析思路，如果有不對的地方，請大家指正

來自于

http://qingfeng825.iteye.com/blog/363283