1、如何給多個子系統設計一個簡單通用的許可權管理方案
1.程序集和項目的關系，程序集，就是把.CS文件編譯後生成的存放CLR能識別的MSIL語言(微軟中間語言)的一個文件（如一個DLL文件或者一個exe文件都叫一個
2、誰能提供一個關於用戶角色許可權設計完整的方案。謝謝
User：用戶表，存放用戶信息
Role：角色表，存放角色信息
UserInRole：用戶角色映射表，存放用戶和角色的對就關系，多對多，一個用戶可以對應多個
角色，而不同的角色有一同的許可權。
Permissions：許可權表，不同的角色對應不同的許可權。許可權信息使用一個欄位flag來表示，
好處是可以使用位運算來計算許可權，缺點是用位標識的許可權受理論值限制，如int理論上可以
標識31種不同的許可權, 當然可以整加一個欄位來彌補，ApplicationID標識不同的模塊
Application：模塊信息。
[Flags]
public enum Flag:long
{
View=1,
Edit=2,
Delete=4
}
特性[Flag]告訴編譯器,當編譯器看到Flag枚舉時，它會充許你用|(or)操作符組合枚舉值，
就像二的整數冪一樣，
例如 Flag Administer=Flag.View|Flag.Edit|Flag.Delete;表示三種許可權的組合。
基礎知識：
位運算
枚舉Flag
當編譯器看到Flag枚舉時，它會充許你用|(or)操作符組合枚舉值，
就像二的整數冪一樣，
例如 Flag Administer=Flag.View|Flag.Edit|Flag.Delete;
常用操作，檢查是否存在
Flag administer=Flag.View|Flag.Edit|Flag.Delete;
public bool Check(Flag administer,Flag mask)
{
bool bReturn = false;
if ((administer & mask) == mask)
bReturn = true;
return bReturn;
}
調用 Check(administer,Flag.Edit)將返回true.
public Flag SetBit(Flag administer,Flag mask)
{
return administer |= mask;
}
administer |= mask;操作相當於 administer = administer |mask;
從枚舉中減去一種狀態
administer &=mask;
如 :
Flag administer=Flag.View|Flag.Edit|Flag.Delete;
如需要禁止刪除許可權.
administer &=Flag.Delete;
另外，標記為flag的枚舉類型，可以不設置值
public enum Flag:long
{
View,
Edit,
Delete
}
如需要設置，按以下規律， View=1,Edit=2,Delete=4,Reply=8按2次方累加，為什麼會這樣？因為他使用二進制操作，
當你使用 View=1,Edit=2,Delete=3,Reply=4這樣的值， Flag.Delete 包含的值是Flag.Delete還是View=1|Edit=2就無從檢測了.
每個用戶，可以屬於不同的角色不同的角色分配不同的許可權，計算所有解權的所有可能的許可權組合，只要有充許的許可權，那麼該用戶既獲取該許可權。
在CS系統中，Permissions表合用了二個欄位來標識許可權.
AllowMask,DenyMask 規責是Deny優先,也就是說當許可權標記為Deny那麼不論是否Allow一律禁止該用戶進行此項操作。
另外，像論壇類的許可權設計，僅僅一個ApplicationID欄位是不夠用的，因為每個版塊都需要設置不同的許可權，來控制許可權的粒度，可在增加一張Permission表，ApplicationID修改為版塊ID
這樣，就可以針對不同的版塊設置不同的許可權
好了，接下的問題是怎麼和.net自帶的許可權系統掛鉤了。。
在asp.net系統中 ，HttpContext.Current.User實現了一個介面IPrincipal,IPrincipal包含了另一個介面Identity
我們在設計User類的時候繼承此介面
public class User:IPrincipal
{
string username;
public string Username
{
get{return username;}
set{username=value;}
}
}
實現IPrincipal介面方法
public IIdentity Identity
{
get {
if (!string.IsNullOrEmpty(username))
_Identity = new GenericIdentity(username,"Forums");
return (IIdentity)_Identity;
}
}
public bool IsInRole(string role)
{
.....
}
怎樣和asp.net掛鉤呢，這里可以在登陸時做檢查
if(HttpContext.Current!=null){
User u= Users.GetUser(name);
HttpContext.Current.User =u;
在使用時
User u = HttpContext.Current.User as User;
當然檢查用戶角色可以直接用
if(HttpContext.Current.User.Identity.IsAuthenticated&&HttpContext.Current.User.IsInRole(角色名))
另外可以直接把到當用戶許可權策略掛接到當前線程 ,使用以下方法
AppDomain.CurrentDomain.SetPrincipalPolicy(User);
好了，接下來，怎麼check許可權？
我傾向於使用Attribute
[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method | AttributeTargets.Property | AttributeTargets.Delegate, Inherited = true, AllowMultiple = true)]
public class CheckPermissionAttribute : Attribute
{
int appID;
public int ApplicationID
{
get { return appID; }
set { appID = value; }
}
Permission _allMask;
public Permission AllMask
{
get { return _allMask; }
set { _allMask = value; }
}
public CheckPermissionAttribute(ApplicationID app, Permission allMask)
{
appID = app;
_allMask = allMask;
}
public CheckPermissionAttribute(Permission allMask)
{
_allMask = allMask;
}
}
AttributeUsage 第一個參數表示該屬性可以應用於類，方法，屬性，代理上
Inherited 檢查繼承的許可權。
AllowMultiple 充許多次應用。
按下來，設計一個基類,繼承自Page：
public class PageBase : Page
{
Flag _allMask;
/// <summary>
/// 檢查類型許可權
/// </summary>
public void CheckClass()
{
Type type = this.GetType();
CheckPermissionAttribute att = (CheckPermissionAttribute)CheckPermissionAttribute.GetCustomAttribute(type, typeof(CheckPermissionAttribute));
if (att != null)
{
Check(att.AllMask);
}
}
/// <summary>
/// 檢查函數調用許可權
/// </summary>
/// <param name="methodName">方法名</param>
public void CheckMethod(string methodName)
{
Type type = this.GetType();
string name = "*";
if (!string.IsNullOrEmpty(methodName))
name = methodName;
MemberInfo[] mis = type.FindMembers(MemberTypes.Method ,BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.IgnoreCase,Type.FilterNameIgnoreCase,name);
foreach (MethodInfo m in mis)
{
CheckPermissionAttribute att = (CheckPermissionAttribute)CheckPermissionAttribute.GetCustomAttribute(m, typeof(CheckPermissionAttribute));
if (att != null)
{
Check(att.AllMask);
}
}
return;
}
public void Check(Flag permissions)
{
if (!CheckPermission(permissions))
{
string url = string.Format("MsgPage.aspx?msg={0}", HttpUtility.UrlEncode("您沒有許可權訪問該資源"));
Response.Redirect(url);
}
}
public void Check(ApplicationID appID, Flag permissions)
{
PermissionManager pm= Spaces.PermissionManager.Instance(appType);
if (!CheckPermission(pm,permissions))
{
string url = string.Format("MsgPage.aspx?msg={0}", HttpUtility.UrlEncode("您沒有許可權訪問該資源"));
Response.Redirect(url);
}
}
protected override void OnInit(EventArgs e)
{
CheckClass();
base.OnInit(e);
}
}
如何使用：
[CheckPermission(2, Flag.View)]
public partial class MyPage : PageBase
{
}
若沒有查看許可權，會自運導向錯誤頁面。
在類上應用挺方便。
方法上應用我於一個方法比較麻煩，我還沒有找到在頁面class里怎麼獲取當前調用的類名.
可以調用 CheckMethod(方法名稱);如
[CheckPermission(2, Flag.Delete)]
public partial class MyPage : PageBase
{
public void test()
{
CheckMethod("test");
.......
}
}
3、大家的許可權都是怎麼實現的，有什麼好的方案沒有？ 歡迎交流如題 謝謝了
多角色的情況一般來說是很普遍的，很難將每一個用戶的功能都抽象為角色進行單一的角專色賦權屬。給給用戶單獨賦予許可權是一種變通的解決辦法，但是一不小很容易失控造成角色和許可權的混亂。 數據許可權如果有兩個或更多維度的話應該如何處理呢? 比如：分地區、類型兩種維度 省日化經理只能看本省范圍內日化產品的銷售情況，城市經理能看到本市范圍全部商品的銷售情況等等 如果不同的角色對於同一個功能有不同的數據范圍要求，如何能設計一個良好的通用模型？。 查看原帖>>
4、怎麼做後台的許可權管理模塊
需要做一個cms網站，PHP+MySQL的，網站後台要有不同角色的不同管理許可權，比如超級管理員擁有所有管專理許可權，編輯員只能發布屬信息，審核員只能刪除垃圾文章圖片。------解決方案--------------------------------------------------------探討需要做一個cms網站，PHP+MySQL的，網站後台要有不同角色的不同管理許可權，比如超級管理員擁有所有管理許可權，編輯員只能發布信息，審核員只能刪除垃圾文章圖片。
5、asp 如何設置瀏覽許可權
使用 Internet 信息服務 (IIS) 管理器，可以創建用來承載 ASP.NET Web 應用程序的本地網站。本主題解內釋如何創建本地網站以及如容何將它配置為運行 ASP.NET 頁。有關安裝和配置 IIS 或者創建網站的更多詳細信息，請參見包含在 IIS 中的 IIS 幫助文檔或者 Microsoft TechNet 網站上的聯機 IIS 產品文檔。
創建本地站點的另一種方法是創建虛擬目錄。這提供了一種實現如下方案的方法：在一台計算機上承載網站，而將該網站的實際頁和內容包含在根目錄或主目錄以外的某個位置，如遠程計算機。這也是一種為本地 Web 開發工作設置站點的方便方法，因為它不需要唯一的站點標識，這意味著它比創建唯一站點所需要的步驟少
6、基於RESTful API 怎麼設計用戶許可權控制
本文是基於RESTful描述的，需要你對這個有初步的了解。
RESTful是什麼？
Representational State Transfer，簡稱REST，是Roy Fielding博士在2000年他的博士論文中提出來的一種軟體架構風格。
REST比較重要的點是資源和狀態轉換，
所謂"資源"，就是網路上的一個實體，或者說是網路上的一個具體信息。它可以是一段文本、一張圖片、一首歌曲、一種服務，總之就是一個具體的實在。
而"狀態轉換"，則是把對應的HTTP協議裡面，四個表示操作方式的動詞分別對應四種基本操作：
1. GET，用來瀏覽(browse)資源
2. POST，用來新建(create)資源
3. PUT，用來更新(update)資源
4. DELETE，用來刪除(delete)資源。
資源的分類及操作
清楚了資源的概念，然後再來對資源進行一下分類，我把資源分為下面三類：
1. 私人資源 (Personal Source)
2. 角色資源 (Roles Source)
3. 公共資源 (Public Source)
"私人資源"：是屬於某一個用戶所有的資源，只有用戶本人才能操作，其他用戶不能操作。例如用戶的個人信息、訂單、收貨地址等等。
"角色資源"：與私人資源不同，角色資源范疇更大，一個角色可以對應多個人，也就是一群人。如果給某角色分配了許可權，那麼只有身為該角色的用戶才能擁有這些許可權。例如系統資源只能夠管理員操作，一般用戶不能操作。
"公共資源"：所有人無論角色都能夠訪問並操作的資源。
而對資源的操作，無非就是分為四種：
1. 瀏覽 (browse)
2. 新增 (create)
3. 更新 (update)
4. 刪除 (delete)
角色、用戶、許可權之間的關系
角色和用戶的概念，自不用多說，大家都懂，但是許可權的概念需要提一提。
"許可權"，就是資源與操作的一套組合，例如"增加用戶"是一種許可權，"刪除用戶"是一種許可權，所以對於一種資源所對應的許可權有且只有四種。
角色與用戶的關系：一個角色對應一群用戶，一個用戶也可以扮演多個角色，所以它們是多對多的關系。
角色與許可權的關系：一個角色擁有一堆許可權，一個許可權卻只能屬於一個角色，所以它們是一(角色)對多(許可權)的關系
許可權與用戶的關系：由於一個用戶可以扮演多個角色，一個角色擁有多個許可權，所以用戶與許可權是間接的多對多關系。
需要注意兩種特別情況：
1. 私人資源與用戶的關系，一種私人資源對應的四種許可權只能屬於一個用戶，所以這種情況下，用戶和許可權是一(用戶)對多(許可權)的關系。
2. 超級管理員的角色，這個角色是神一般的存在，能無視一切阻礙，對所有資源擁有絕對許可權，甭管你是私人資源還是角色資源。
資料庫表的設計
角色、用戶、許可權的模型應該怎麼樣設計，才能滿足它們之間的關系？
對上圖的一些關鍵欄位進行說明：
Source
name: 資源的名稱，也就是其他模型的名稱，例如：user、role等等。
identity: 資源的唯一標識，可以像uuid，shortid這些字元串，也可以是model的名稱。
permissions : 一種資源對應有四種許可權，分別對這種資源的browse、create、update、delete
Permission
source : 該許可權對應的資源，也就是Source的某一條記錄的唯一標識
action ：對應資源的操作，只能是browse、create、update、delete四個之一
relation：用來標記該許可權是屬於私人的，還是角色的，用於OwnerPolicy檢測
roles: 擁有該許可權的角色
Role
users : 角色所對應的用戶群，一個角色可以對應多個用戶
permissions: 許可權列表，一個角色擁有多項權利
User
createBy : 該記錄的擁有者，在user標里，一般等於該記錄的唯一標識，這一屬性用於OwnerPolicy的檢測，其他私有資源的模型設計，也需要加上這一欄位來標識資源的擁有者。
roles : 用戶所擁有的角色
策略/過濾器
在sails下稱為策略(Policy)，在java
SSH下稱為過濾器(Filter)，無論名稱如何，他們工作原理是大同小異的，主要是在一條HTTP請求訪問一個Controller下的action
之前進行檢測。所以在這一層，我們可以自定義一些策略/過濾器來實現許可權控制。
為行文方便，下面姑且允許我使用策略這一詞。
*策略 (Policy) *
下面排版順序對應Policy的運行順序
SessionAuthPolicy：
檢測用戶是否已經登錄，用戶登錄是進行下面檢測的前提。
SourcePolicy：
檢測訪問的資源是否存在，主要檢測Source表的記錄
PermissionPolicy：
檢測該用戶所屬的角色，是否有對所訪問資源進行對應操作的許可權。
OwnerPolicy：
如果所訪問的資源屬於私人資源，則檢測當前用戶是否該資源的擁有者。
如果通過所有policy的檢測，則把請求轉發到目標action。
7、請教XX管理系統的前端頁面展示和後端許可權控制的一般解決方案
前端面向的是抄用戶編程，就襲是用戶可以看得到摸得到的。UI就是其中的一部分。後端是面向服務(伺服器)編程，用戶是無須知道裡面的操作的。舉個例子。比如簡單的登陸功能。前端的只要做好兩個文本控制項與一個按鈕控制項，並且監聽按鈕的點擊事件，將兩個文本的參數按照協議發送到伺服器端上。這就是前端要做的。而後端，伺服器就要接收發送過來的消息並且調用資料庫驗證用戶名與密碼。成功後返回結果。
8、JAVA許可權設計模塊，設計思路。網上的不要，請根據我的需求來，謝謝了啊。好了我還會加分。
不知來道你們的需求要細到什麼自程度，只能說個大概
最基本的許可權管理是要定義角色和許可權
每個用戶都有若干角色身份，比如項目負責人，項目參與者都是角色
許可權就是操作，比如下載數據，瀏覽項目這些都是許可權
角色表和許可權表是多對多的關系
如果要給某個用戶分配某個許可權，就把一個許可權和一個角色關聯起來，同時確保這個用戶有這個被關聯的角色身份，這樣就可以通過用戶查角色，通過角色查關聯許可權，如果用戶有關聯當前操作需要的許可權，就可以通過了。
以上是粗粒度的方法級許可權管理的基本思想
細粒度的數據級許可權控制要復雜得多，比如有兩個項目，兩個用戶分別是它們的項目組長，而每個用戶只能管自己的那個項目組，因為他們角色都是項目組長，所以就不能用上面的方法來驗證許可權了。
解決方案說來話長，採納以後可以hi我詳細說
授權時間可以使用定時器，到一定時間以後將角色和許可權的關聯關系刪掉，也可以定期輪循檢查，發現有許可權過期了就刪掉，前提當然是你的許可權關聯要記好生效時間和有效期
9、軟體設計後台操作用戶許可權管理的方案
B/S系統中的許可權比C/S中的更顯的重要，C/S系統因為具有特殊的客戶端，所以訪問用戶的許可權檢測可以通過客戶端實現或通過客戶端+伺服器檢測實現，而B/S中，瀏覽器是每一台計算機都已具備的，如果不建立一個完整的許可權檢測，那麼一個「非法用戶」很可能就能通過瀏覽器輕易訪問到B/S系統中的所有功能。因此B/S業務系統都需要有一個或多個許可權系統來實現訪問許可權檢測，讓經過授權的用戶可以正常合法的使用已授權功能，而對那些未經授權的「非法用戶」將會將他們徹底的「拒之門外」。下面就讓我們一起了解一下如何設計可以滿足大部分B/S系統中對用戶功能許可權控制的許可權系統。
需求陳述
不同職責的人員，對於系統操作的許可權應該是不同的。優秀的業務系統，這是最基本的功能。
可以對「組」進行許可權分配。對於一個大企業的業務系統來說，如果要求管理員為其下員工逐一分配系統操作許可權的話，是件耗時且不夠方便的事情。所以，系統中就提出了對「組」進行操作的概念，將許可權一致的人員編入同一組，然後對該組進行許可權分配。
許可權管理系統應該是可擴展的。它應該可以加入到任何帶有許可權管理功能的系統中。就像是組件一樣的可以被不斷的重用，而不是每開發一套管理系統，就要針對許可權管理部分進行重新開發。
滿足業務系統中的功能許可權。傳統業務系統中，存在著兩種許可權管理，其一是功能許可權的管理，而另外一種則是資源許可權的管理，在不同系統之間，功能許可權是可以重用的，而資源許可權則不能。
關於設計
藉助NoahWeb的動作編程理念，在設計階段，系統設計人員無須考慮程序結構的設計，而是從程序流程以及資料庫結構開始入手。為了實現需求，資料庫的設計可謂及其重要，無論是「組」操作的概念，還是整套許可權管理系統的重用性，都在於資料庫的設計。
我們先來分析一下資料庫結構：
首先，action表（以下簡稱為「許可權表」），gorupmanager表（以下簡稱為「管理組表」），以及master表（以下簡稱為「人員表」），是三張實體表，它們依次記錄著「許可權」的信息，「管理組」的信息和「人員」的信息。如下圖：
這三個表之間的關系是多對多的，一個許可權可能同時屬於多個管理組，一個管理組中也可能同時包含多個許可權。同樣的道理，一個人員可能同時屬於多個管理組，而一個管理組中也可能同時包含多個人員。如下圖：
由於這三張表之間存在著多對多的關系，那麼它們之間的交互，最好使用另外兩張表來完成。而這兩張表起著映射的作用，分別是「actiongroup」表（以下簡稱「許可權映射表」）和「mastergroup」表（以下簡稱「人員映射表」），前者映射了許可權表與管理組表之間的交互。後者映射了人員表與管理組表之間的交互。如下圖：
另外，還需要一張表來控制系統運行時左側菜單中的許可權分欄，也就是「許可權分欄表」，如下圖：
根據上面的分析，我們進行資料庫結構設計，如下圖：
點擊這里查看許可權管理系統數據表欄位設計
為了能夠進行良好的分析，我們將資料庫結構圖拆分開來，三張實體表的作用已經很清晰，現在我們來看一下兩張映射表的作用。
一 許可權映射表 如下圖：
首先，我們來了解一下許可權映射表與管理組表以及許可權表之間的欄位關聯。
看圖中的紅圈，先看gorupid欄位相關聯，這種關聯方式在實際資料庫中的表現如下圖：
如圖中所示，管理組表中「超級管理員」的groupid為1，那麼許可權映射表中groupid為1的許可權也就是「超級管理員」所擁有的許可權。
使用groupid欄位關聯，是為了查到一個管理組能夠執行的許可權有哪些。但這些許可權的詳細信息卻是action欄位關聯所查詢到的。
action欄位相關聯在資料庫中的表現如下圖：
通過這種關聯，才查詢到許可權映射表之中那些許可權的詳細信息。綜合起來，我們就知道了一個管理組可以執行的許可權有哪些，以及這些許可權的詳細信息是什麼。
或許你會問，為什麼不使用actionid欄位相關聯呢？因為：
許可權表中的id欄位在經過多次的資料庫操作之後可能會發生更改。
許可權映射表中僅僅記錄著一個管理組可以執行的許可權。
一旦許可權表中的id更改，那麼許可權映射表中的記錄也就更改了。
一個管理組可以執行的許可權勢必將出錯，這是非常不希望的。
考慮到上面的情況，所以應該使用action欄位相關聯，因為：
在許可權表中，id可能發生變化，而action欄位卻是在任何情況下也不可能發生變化的。
許可權映射表中記錄的action欄位也就不會變。
一個管理組可以執行的許可權就不會出錯了。
二 人員映射表 如下圖：
我們來了解一下人員映射表與管理組表以及人員表之間的欄位關聯，如下圖：
看圖中的紅圈部分，先看groupid欄位關聯，這種關聯方式在資料庫中的表現如下圖：
如圖，「超級管理員」組的groupid為1，我們再看人員映射表，admin屬於超級管理員組，而administrator屬於超級管理員組，同時也屬於管理員組。
使用這種關聯方式，是為了查到一個管理組中的人員有誰。和上面一樣，人員的詳細信息是靠id欄位（人員映射表中是masterid欄位）關聯查詢到的。
id欄位（人員映射表中是masterid欄位）關聯表現在資料庫中的形式如下圖：
一個人員可能同時屬於多個「管理組」，如圖中，administrator就同時屬於兩個「管理組」。所以，在人員映射表中關於administrator的記錄就會是兩條。
這種關聯方式才查詢到管理組中人員的詳細信息有哪些。綜合起來，才可以知道一個管理組中的人員有誰，以及這個人員的詳細信息。
再結合上面談到的許可權表和許可權映射表，就實現了需求中的「組」操作，如下圖：
其實，管理組表中僅僅記錄著組的基本信息，如名稱，組id等等。至於一個組中人員的詳細信息，以及該組能夠執行的許可權的詳細信息，都記錄在人員表和許可權表中。兩張映射表才真正記錄著一個組有哪些人員，能夠執行哪些許可權。通過兩張映射表的銜接，三張實體表之間的交互才得以實現，從而完成了需求中提到的「組」操作。
我們再來看一下許可權分欄表與許可權表之間的交互。這兩張表之間的欄位關聯如下圖：
兩張表使用了actioncolumnid欄位相關聯，這種關聯方式在資料庫中的表現如下圖：
如圖所示，通過這種關聯方式，我們可以非常清晰的看到許可權表中的許可權屬於哪個分欄。
現在，資料庫結構已經很清晰了，分配許可權的功能以及「組」操作都已經實現。下面我們再來分析一下需求中提到的關於許可權管理系統的重用性問題。
為什麼使用這種資料庫設計方式搭建起來的系統可以重用呢？
三張實體表中記錄著系統中的三個決定性元素。「許可權」，「組」和「人」。而這三種元素可以任意添加，彼此之間不受影響。無論是那種類型的業務系統，這三個決定性元素是不會變的，也就意味著結構上不會變，而變的僅僅是數據。
兩張映射表中記錄著三個元素之間的關系。但這些關系完全是人為創建的，需要變化的時候，只是對資料庫中的記錄進行操作，無需改動結構。
許可權分欄表中記錄著系統使用時顯示的分欄。無論是要添加分欄，修改分欄還是減少分欄，也只不過是操作記錄而已。
綜上所述，這樣設計資料庫，系統是完全可以重用的，並且經受得住「變更」考驗的。
總結：
此套系統的重點在於，三張實體表牢牢地抓住了系統的核心成分，而兩張映射表完美地映射出三張實體表之間的交互。其難點在於，理解映射表的工作，它記錄著關系，並且實現了「組」操作的概念。而系統總體的設計是本著可以在不同的MIS系統中「重用」來滿足不同系統的功能許可權設置。
附錄：
許可權管理系統數據表的欄位設計
下面我們來看看許可權管理系統的資料庫表設計，共分為六張表，如下圖：
action表：
action表中記錄著系統中所有的動作，以及動作相關描述。
actioncolumn表：
actioncolumn表中記錄著動作的分欄，系統運行時，左側菜單欄提供了幾塊不同的功能，每一塊就是一個分欄，每添加一個分欄，該表中的記錄就會增加一條,相對應的，左側菜單欄中也會新增機一個欄。
actiongroup表：
actiongroup表記錄著動作所在的組。
groupmanager表：
groupmanager表記錄著管理組的相關信息，每添加一個管理組，這里的記錄就會增加一條。
mastergroup表：
mastergroup表記錄著管理員所在的管理組，由於一名管理員可能同同時屬於多個組，所以該表中關於某一名管理員的記錄可能有多條。
master表：
master表記錄著所有管理員的信息，每添加一個管理員，該表就會增加一條記錄。