許可權設計
大概有這幾種模式：
使用者+組+角色+許可權
使用者+組+許可權
使用者+角色+許可權
使用者+許可權
最近看了別人的設計方法，大多以「整數」來表示許可權值，如新增、瀏覽、刪除和修改，分別用1、2、4、8這幾個整數來代替，不過，各人的做法有所不同，舉例如下：
1. 用2的n次冪組成許可權值的集合，如1、2、4、8、16...，某使用者的許可權值為其子集中的整數之和，如 7=1+2+4，5=1+4。如果要從資料庫檢索包含某幾種許可權的使用者，則先把這幾種許可權值相加，假設和為k，然後select * from table where 1 and 使用者許可權值 = 'k'；如果要判斷某使用者有哪些許可權，則取出其許可權值k，分別用k&1,k&2,k&4,k&16...,如果為真，則 表示有值等於「&」右邊整數的許可權，例如，如果k&4為真，則此使用者有許可權表中值等於4的許可權；
2.用質數2、3、5、 7、11...組成許可權集合，某使用者的許可權為其子集中各整數的乘積，如 210 = 2*3*5*7,我覺得這種方法很有趣，難點在於如何分解質因數；但我有些不認同原作者的提法，他認為許可權之間可能存在包含關係，如某使用者有刪除許可權，則 其一定有瀏覽許可權，要不然就沒法刪除，事實確實是這樣，不過我認為這樣太複雜了，容易出錯，我覺得許可權最好是「原子」的，互不干擾，也就是說某使用者有刪除 許可權而沒瀏覽許可權則其無法進行刪除操作，因為他看不到東西，解決這個矛盾的關鍵是在給使用者賦權時，把瀏覽許可權也賦給他；
3.不用整數，而 是用「向量表」方法（也許我說的不一定對），把所有可能的許可權按一定的順序排列，如新增、瀏覽、修改、刪除...，使用者的許可權值為固定100位長度的字元 串，如100010100001....01，從左起每一位對應一種操作許可權，如果有這種許可權，則此位的值為1，反之，則為0，作者之所以把使用者許可權值固 定為100位，我想是考慮到公升級問題，但我認為這還不夠科學，我認為使用者的許可權值長度應小於許可權個數，舉例如下：
許可權排列表：新增、瀏覽、修改、刪除，使用者a有新增和瀏覽的的許可權，則其許可權值為11，使用者b有瀏覽和修改的許可權則其許可權值為011，使用者c有瀏覽和刪除的許可權則其許可權值為0101，這樣設計的好處為：當許可權表中增加別的許可權時，不會影響使用者表或角色表；
4. 我曾經的做法，在後台管理中把許可權分為兩大類：欄目許可權和操作許可權，每個欄目對應乙個目錄，操作許可權細分為瀏覽、新增、修改和刪除，使用者進入系統後首先判 斷有沒有欄目許可權，然後判斷有沒有操作許可權，判斷欄目許可權相對簡單一些，首先獲取訪問頁面的路徑path，然後分解出目錄，對應使用者擁有的目錄許可權，如果 此目錄包含在使用者有權管理的目錄陣列中（從資料庫取出），則其有進入此目錄的許可權，否則，沒有，然而，在判斷操作許可權好象有些麻煩，但突然想到新增、瀏 覽、修改和刪除與我的檔案命名規則是基本是對應的，但有點不同的是，我把新增和刪除的功能合併在乙個檔案中了，例如檔名為 proaddedit.php，幸好意識到修改檔案時多了個傳遞引數id，於是，我用正則解決了這個問題，今天看來，這種方法似乎過時了，因為不適應面向 物件的思想和用框架體系來開發系統！
許可權設計（功能許可權與資料許可權）
許可權設計的最終目標就是定義每個使用者可以在系統中做哪些事情。當我們談到許可權的時候，一般可以分為 功能許可權 資料許可權和字段許可權 功能許可權 使用者具有哪些權利，比如特定單據的增 刪 改 查 審批 反審批等等 一般按照乙個人在組織內的工作內容來劃分 比如乙個單據往往有錄入人和審批人，錄入人具有...
與非許可權總結
許可權總結 1.許可權類別有 序號 名稱 值 1 讀 1 2 查詢 2 3 寫 4 4 更新 8 5 刪除 16 6 2.增加許可權 我的許可權值 讀 查詢 寫 更新 我的許可權值 1 2 4 8 15 增加刪除許可權 我的許可權值 我的許可權值 刪除 我的許可權值 15 16 31 3.刪除許可權...
SAP 許可權與角色設計
原文 角色 通用角色 本地角色 許可權物件 mm x 物件 許可權字段 欄位一 負責增刪改 欄位二 負責字段級准入 允許操作 01 03 05 07 允許值 factory1,factory2,factory5 factory7 直觀的說，許可權就是 某人能幹某事 和 某人不能幹某事 之合。在sap...