使用者角色許可權

我感覺，雖然很多人都可以做出一個成員資格管理的模組，但是能做的好的並不是很多。其中，有對這個成員管理原理不清楚的，也有實現能力不強的，等等。我覺得，要想做好成員資格管理，首先必須對成員資格管理的概念和原理有較為深刻的認識。然後，有個好的設計和實現。

所以，我將在下面和大家一起討論一下成員資格管理的概念和原理。

在成員資格管理中有3個很重要的概念：使用者，角色，許可權。

使用者是一個在商務邏輯中存在的實體或者虛實體（不可見，但存在）。使用者帶有某種目的和權利。

角色是具有某些共性的使用者組成的集合（這個集合允許為空白）。

許可權是規定了的一系列的訪問規則。許可權的本質是規則。是規定哪些使用者可以做哪些事情，哪些使用者不可以做哪些事情的規則。

比如說，只有擁有經理的角色才能查看報表。我們解析的時候是這樣的：有這麼一批人可以查看報表，這批人有個共同的特徵，那就是他們擁有經理的角色。經理的角色特徵是，在現實的商務邏輯中是經理或者擁有經理一樣高的權利。

在許可權中定義的是使用者和事情之間的關係，並沒有涉及到角色。所以，如果不使用角色也可以實現成員資格管理。但是，角色作為某些使用者的集合，這樣對制定規格是更為方便、合理，也更符合商務邏輯的客觀存在形式。

使用者和角色的優先順序：
在同一個功能操作的存取權限下，一個使用者被拒絕/允許，但這個使用者的角色卻被允許/拒絕，那這個使用者到底能不能執行這個功能操作？我們給出的答案的否定的。也是就如果有明確使用者可以做或不能做則按照這個規定！為什麼呢，因為角色只是為了更好的組織使用者，它代表了一類的使用者。但是這類人中必然存在差異性，直接明確使用者訪問規則就是為了承認或者實現這種差異性。使用者具有原子性，但是角色是由使用者組成的，所以它不具備原子性。只有原子性的對象才能夠保證這個訪問規則的正確性。

拒絕和允許的優先順序：
allow 和 deny 的優先順序，到底哪個高呢？由於使用者可以有多個角色，但這些角色中有些角色被一訪問規則允許，有些則被禁止，有些未定義。這時，我們是讓這個使用者通過還是拒絕通過。我們認為應該拒絕使用者的通過。正是使用者角色的複雜性，所以在沒有足夠證據證明“裡面的有些角色被拒絕但實際上這個使用者不應該拒絕”的情況下，應該先把這個使用者拒絕掉。這也是出於安全性的考慮。

關於企業單位中的部門設定與角色的關係:
我認為部門是一個角色，是一個和現實有密切聯絡的特殊角色。這個角色中包含了一系列的使用者（這個部門的員工，這個部門的電腦（虛擬使用者）等等）