許可權設計是很多系統重要的組成部分，主要用於控制功能和流程，本文將幾種常見的許可權設計方案（許可權系統的名都是自己起的）的基本設計寫出來，其中不恰當處還請大家指出，我們來討論一下.
1.等級許可權系統
這種許可權系統在論壇中很常見，在這種系統中，許可權級別如同官階從低到高排列，每個使用者擁有乙個許可權，其中設定了這個使用者的許可權等級，在使用者需要執行操作前先檢視其許可權等級是否大於執行操作所需要的許可權等級，是則進行操作。
在等級許可權系統中領域物件使用者類user的基本屬性如下：
id // 使用者id
name // 使用者名稱
領域物件許可權類privilege的基本屬性如下:
id // 許可權id
userid // 持有此許可權的使用者id
level // 使用者的許可權等級
level的設定示例
level 對應可執行的功能
0 訪問
1 可跟帖
2 可建立主貼
3 可刪除主貼
4 可建立頻道
5 可刪除頻道
6 可檢視使用者
7 可分配使用者許可權
8 可修改使用者密碼
9 可刪除使用者
...使用中,執行乙個操作比如建立主貼時,先從session中取出使用者,然後按其id查出其對應的許可權等級,拿它和執行建立主貼所需要的等級(3)進行比較,高於則可進行建立主貼操作,否則報告許可權不夠.
等級許可權系統簡單易用,在如論壇等剛性控制系統中使用很好,但不適用於需要限制許可權的範圍的場合。
2.範圍限制許可權系統
等級許可權系統系統的缺點是控制範圍過廣,比如乙個論壇中有很多子論壇,乙個子論壇的分版主同時也能對另乙個同等級分論壇的帖子進行控制,這在一定程度不合理，有越界的嫌疑,更好的做法是將版主許可權控制在一版之內,這時我們可以採用範圍限制許可權系統. 這種許可權系統在專案管理系統中很常見.
在等級許可權系統中領域物件使用者類user的基本屬性如下：
id // 使用者id
name // 使用者名稱
領域物件專案類project的基本屬性如下：
id // 專案id
name // 專案名
領域物件許可權類privilege的基本屬性如下:
id // 許可權id
userid // 持有此許可權的使用者id
projectid // 此許可權對應的專案
level // 使用者的許可權等級
其中,通過引入了新屬性projectid,我們對許可權的範圍進行了有效限制,專案不同則許可權等級再高也是無效,這樣就起到了限制許可權能力範圍的作用.
3.範圍限制單項許可權系統
在上面兩個許可權系統中,許可權高的自然能執行許可權要求低的操作,這樣做權力沒有細分,在有些場合並不合理,比如即使是董事長不可直接操作人事部的招聘任務,他只對雇員去留有建議權.對於這樣的場合我們需要使用範圍限制單項許可權系統.它的典型應用如工作流和oa系統。
在範圍限制單項許可權系統中領域物件使用者類user的基本屬性如下：
id // 使用者id
name // 使用者名稱
領域物件專案類project的基本屬性如下：
id // 專案id
name // 專案名
領域物件許可權類privilege的基本屬性如下:
id // 許可權id
userid // 持有此許可權的使用者id
projectid // 此許可權對應的專案
abilityid // 許可權控制能力id
領域物件許可權控制能力類ability的基本屬性如下:
id // 控制能力id
item // 控制能力子項
item的設定示例
item 對應可執行的功能
0 讀1 寫
2 查3 刪
通過對許可權能力的細分,使用者許可權的控制粒度更細了,對功能和流程就能有更精確的把握,適用於複雜的場合.
以上三種許可權系統沒有優劣之分只有適用場合的區別,前面的粗略但易於操作,後面的精確但失之煩瑣,在現實使用中我們應該根據場合選擇合適的許可權系統.
C C 中煉表的三種設計方案
1.一般做法，用具體資料結構封裝鍊錶。struct data 上邊這個例子，在data結構中有個next域，通過這個就可以組成乙個鍊錶，這個是我讀書時最常用的模式。缺點在於 每種具體的結構都要寫一遍鍊錶的增刪查改操作，重複了n多。2.stl的做法 用鍊錶封裝具體資料結構。struct data li...
MySQL許可權開通的設計方案
mysql中的許可權管理和其他資料庫還是有很大的不同，它能夠實現幾種很特別的許可權場景 幾個人公用乙個賬號，看起來使用者名稱相同，密碼相同，但是許可權缺可以不同 幾個人用同乙個賬號，使用者名稱相同，但是密碼可以不同，許可權可以相同 幾個人用同乙個賬號，使用者名稱相同，但是密碼可以不同，許可權可以不同...
許可權管理之基於RBAC的設計方案
rbac role based accesscontrol，基於角色的訪問控制 就是使用者通過角色與許可權進行關聯。簡單地說，乙個使用者擁有若干角色，每乙個角色擁有若干許可權。這樣，就構造成 使用者 角色 許可權 的授權模型。與acl 實現的區別在於，不能直接為使用者分配許可權，只能從角色那裡繼承而...