用戶權限表結構

我有一個帶有許多受限區域的PHP腳本。在這些區域中的每一箇中，我都有一個函數，通過檢查「usergroup」表來檢查用戶是否有權訪問當前區域。這個問題是我現在有超過100列，所以我不確定這是否是一個正確的數據庫設計。用戶權限表結構

來源

2010-02-17 Essam

我認爲這可能是不正確的做法。

你應該像

羣組不見了的東西

UserGroupID
UserGroupDescription

UserGroupRules

RuleID
RuleSection
RuleSubSection

UserGroupRuleLinks

UserGroupID
RuleID

然後可以簡單地檢查組是否具有相關的適當規則。

來源

2010-02-17 04:55:24

有些人會告訴你去使用基於角色的權限結構，但我更喜歡自己的二進制權限。回想一天，我會使用一個int字段，它會給我32個不同的標誌，我可以設置。權限表將包含每個標誌的名稱和值，許可證表將包含適用於每個用戶的所有權限。我還實現了一個組結構，並將權限字段分爲允許和拒絕，這給了我很大的靈活性。本質上的權限將被計算就像這樣：

AllowMask = userPermit.AllowPermissions; 
DenyMask = userPermit.DenyPermissions; 
foreach(groupPermit in groups.UserMemberOf(UserID)) 
{ 
    AllowMask = AllowMask | groupPermit.AllowPermissions; 
    DenyMask = DenyMask | groupPermit.DenyPermissions; 
} 
Permissions = AllowMask & ~DenyMask

，從那裏得到的標誌值和檢查Permissions & FlagValue > 0;

正如你在你的問題指出了一個簡單的事情，但它可能是32個標誌AREN夠了。我遇到了同樣的問題，並開始使用持有base64編碼數字的varchar字段。由於base64字符持有6位，所以我只需確保字符長度是4x4 = 24/8 = 3的四倍。這給了我足夠的空間將4個字符塊轉換爲整數，並在其上運行上述函數。如果一個標誌大於2^24，我會剪掉4個字符，並使用更小的數字。

希望是有道理的。這是一個令人困惑的系統，但一旦運行，它會使權限處理成爲一個夢想。

來源

2010-02-17 05:02:29

從存儲的角度來看，這似乎很好，但從可維護性/查詢方面來看，這會非常困難。 – 2010-02-17 05:14:34

我認爲關於可維護性的唯一主要障礙就是它是一種不常見的方法。然而，對於熟悉布爾邏輯和base64編碼基礎知識的人來說，這是一個可靠的設計。此外，將所有基本的部分抽象爲易於使用的類並不是那麼困難。也許它不適合每個人的目的，但從我自己的經驗來看，它發現它在複雜性和靈活性之間取得了非常舒適的平衡。 – 2010-02-17 09:13:57

隨着時間的推移，這是一個典型的問題。該模型以六種權限開始，隨着時間的推移，它會增長到很長一段時間，此時它變得醜陋和難以管理。我想查看role based access control。您定義了一系列可以分配給用戶的角色。權限然後分配給角色，而不是用戶。這使得用戶管理變得非常簡單，即使對系統知之甚少的用戶也不需要從數百個權限中進行選擇，而是從少量角色中進行選擇。無論何時你需要更多的粒度，簡單地創建新的角色。

它可能看起來令人生畏在第一，但你實際上是在尋找少數幾個表格：

user_role_assn
作用
role_permission_assn
許可
permission_object（查找）
permission_operation（lookup）

幾個月前，我實現了基本的RBAC規範，最初的修訂只花了3-4天的時間來構建和實施。

來源

2010-02-17 05:07:23 Cache

用戶權限表結構

回答

相關問題