我感覺，雖然很多人都可以做出乙個成員資格管理的模組，但是能做的好的並不是很多。其中，有對這個成員管理原理不清楚的，也有實現能力不強的，等等。我覺得，要想做好成員資格管理，首先必須對成員資格管理的概念和原理有較為深刻的認識。然後，有個好的設計和實現。
所以，我將在下面和大家一起討論一下成員資格管理的概念和原理。
在成員資格管理中有3個很重要的概念：使用者，角色，許可權。
使用者是乙個在業務邏輯中存在的實體或者虛實體（不可見，但存在）。使用者帶有某種目的和權利。
角色是具有某些共性的使用者組成的集合（這個集合允許為空）。
許可權是規定了的一系列的訪問規則。許可權的本質是規則。是規定哪些使用者可以做哪些事情，哪些使用者不可以做哪些事情的規則。
比如說，只有擁有經理的角色才能檢視報表。我們解析的時候是這樣的：有這麼一批人可以檢視報表，這批人有個共同的特徵，那就是他們擁有經理的角色。經理的角色特徵是，在現實的業務邏輯中是經理或者擁有經理一樣高的權利。
在許可權中定義的是使用者和事情之間的關係，並沒有涉及到角色。所以，如果不使用角色也可以實現成員資格管理。但是，角色作為某些使用者的集合，這樣對制定規格是更為方便、合理，也更符合業務邏輯的客觀存在形式。
使用者和角色的優先順序：
在同乙個功能操作的訪問許可權下，乙個使用者被拒絕/允許，但這個使用者的角色卻被允許/拒絕，那這個使用者到底能不能執行這個功能操作？我們給出的答案的否定的。也是就如果有明確使用者可以做或不能做則按照這個規定！為什麼呢，因為角色只是為了更好的組織使用者，它代表了一類的使用者。但是這類人中必然存在差異性，直接明確使用者訪問規則就是為了承認或者實現這種差異性。使用者具有原子性，但是角色是由使用者組成的，所以它不具備原子性。只有原子性的物件才能夠保證這個訪問規則的正確性。
拒絕和允許的優先順序：
allow 和 deny 的優先順序，到底哪個高呢？由於使用者可以有多個角色，但這些角色中有些角色被一訪問規則允許，有些則被禁止，有些未定義。這時，我們是讓這個使用者通過還是拒絕通過。我們認為應該拒絕使用者的通過。正是使用者角色的複雜性，所以在沒有足夠證據證明"裡面的有些角色被拒絕但實際上這個使用者不應該拒絕"的情況下，應該先把這個使用者拒絕掉。這也是出於安全性的考慮。
關於企業單位中的部門設定與角色的關係:
我認為部門是乙個角色，是乙個和現實有密切聯絡的特殊角色。這個角色中包含了一系列的使用者（這個部門的員工，這個部門的計算機（虛擬使用者）等等）
rbac（role-based access control，基於角色的訪問控制），就是使用者通過角色與許可權進行關聯。簡單地說，乙個使用者擁有若干角色，每乙個角色擁有若干許可權。這樣，就構造成"使用者-角色-許可權"的授權模型。在這種模型中，使用者與角色之間，角色與許可權之間，一般者是多對多的關係。（如下圖）
角色是什麼？可以理解為一定數量的許可權的集合，許可權的載體。例如：乙個論壇系統，"超級管理員"、"版主"都是角色。版主可管理版內的帖子、可管理版內的使用者等，這些是許可權。要給某個使用者授予這些許可權，不需要直接將許可權授予使用者，可將"版主"這個角色賦予該使用者。
當使用者的數量非常大時，要給系統每個使用者逐一授權（授角色），是件非常煩瑣的事情。這時，就需要給使用者分組，每個使用者組內有多個使用者。除了可給使用者授權外，還可以給使用者組授權。這樣一來，使用者擁有的所有許可權，就是使用者個人擁有的許可權與該使用者所在使用者組擁有的許可權之和。（下圖為使用者組、使用者與角色三者的關聯關係）
在應用系統中，許可權表現成什麼？對功能模組的操作，對上傳檔案的刪改，選單的訪問，甚至頁面上某個按鈕、某個的可見性控制，都可屬於許可權的範疇。有些許可權設計，會把功能操作作為一類，而把檔案、選單、頁面元素等作為另一類，這樣構成"使用者-角色-許可權-資源"的授權模型。而在做資料表建模時，可把功能操作和資源統一管理，也就是都直接與許可權表進行關聯，這樣可能更具便捷性和易擴充套件性。（見下圖）
請留意許可權表中有一列"許可權型別"，我們根據它的取值來區分是哪一類許可權，如"menu"表示選單的訪問許可權、"operation"表示功能模組的操作許可權、"file"表示檔案的修改許可權、"element"表示頁面元素的可見性控制等。
這樣設計的好處有二。其一，不需要區分哪些是許可權操作，哪些是資源，（實際上，有時候也不好區分，如選單，把它理解為資源呢還是功能模組許可權呢？）。其二，方便擴充套件，當系統要對新的東西進行許可權控制時，我只需要建立乙個新的關聯表"許可權xx關聯表"，並確定這類許可權的許可權型別字串。
這裡要注意的是，許可權表與許可權選單關聯表、許可權選單關聯表與選單表都是一對一的關係。（檔案、頁面許可權點、功能操作等同理）。也就是每新增乙個選單，就得同時往這三個表中各插入一條記錄。這樣，可以不需要許可權選單關聯表，讓許可權表與選單表直接關聯，此時，須在許可權表中新增一列用來儲存選單的id，許可權表通過"許可權型別"和這個id來區分是種型別下的哪條記錄。
到這裡，rbac許可權模型的擴充套件模型的完整設計圖如下：
隨著系統的日益龐大，為了方便管理，可引入角色組對角色進行分類管理，跟使用者組不同，角色組不參與授權。例如：某電網系統的許可權管理模組中，角色就是掛在區局下，而區局在這裡可當作角色組，它不參於許可權分配。另外，為方便上面各主表自身的管理與查詢，可採用樹型結構，如選單樹、功能樹等，當然這些可不需要參於許可權分配。
使用者 角色 許可權
最近因為要用到許可權這個東西，感覺腦袋很是有點亂，昨天硬是搞到大半夜才終於理清了思路。現在我就將我的思路和大家分享一下，不敢保證完全正確，大家看看便罷。看看便罷 一般我們使用到 使用者 角色 許可權 這三張表的時候，會發現表裡會有很多字段，然後相對應的外來鍵也是很多，往往我們就容易混亂。現在我這邊列...
使用者角色許可權
rbac role based access control，基於角色的訪問控制 就是使用者通過角色與許可權進行關聯。簡單地說，乙個使用者擁有若干角色，每乙個角色擁有若干許可權。這樣，就構造成 使用者 角色 許可權 的授權模型。在這種模型中，使用者與角色之間，角色與許可權之間，一般者是多對多的關係。...
使用者角色許可權
1 使用者表 sys user idorg id login name password user name phone email create time login time 主鍵id 組織id 使用者登陸名 使用者密碼 使用者姓名 手機號電子郵箱 建立時間 登陸時間 2 角色表 sys rol...