許可權設計及演算法(PHPE)

來源:互聯網
上載者:User
設計|演算法

許可權設計

大概有這幾種模式:
使用者+組+角色+許可權
使用者+組+許可權
使用者+角色+許可權
使用者+許可權


最近看了別人的設計方法,大多以“整數”來表示許可權值,如添加、瀏覽、刪除和修改,分別用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,於是,我用正則解決了這個問題,今天看來,這種方法似乎過時了,因為不適應物件導向的思想和用架構體系來開發系統!

以上是個人粗淺的認識和描述,若有錯誤,請各位指正,希望高人給些意見! 

Posted by: trooman 2005-12-28 16:02
咋個這麼冷清,一個發表點意見的都沒有? 

Posted by: axgle 2005-12-28 16:05
已收藏。 

Posted by: Donyad 2005-12-28 16:41
1 2 3 的思想是相同的,只是實現上的手法不同而已
而3後半部分樓主的例子,恕偶愚笨,看不懂

3的做法是很C的,driver層級或者系統層級的程式很常用
比如*nix下的檔案許可權0755 0777之類

方法1 跟 方法3 原型是一模一樣的,就是二進位位,方法3 是對這個的一個字串類比
二進位 十進位
100 4
+ 1 1
------------
101 5

用相互獨立的位來標誌許可權,就是為了原子性,素數同樣具有這個特性
所以派生出2的做法,而分解質因數,我並不認為這個會是一個問題,因為三種方法都需要去檢查所需要的許可權
既然是檢查,除一下所需要的質數即可

而3裡面所說的要變長的問題
1和2正好在概念上迴避了這個問題
實際上,在C裡面用二進位,有個對齊的問題,就是要8位8位的申請,8位8位的用,無所謂太長了浪費
只是象方法3這樣用字串來類比二進位時會有浪費
而方法1 2在真正儲存時,也是儲存成一個int,也是一個申請過來就那麼多位的二進位空間,無所謂浪費

擴充和彈性上,方法1和方法2是沒有影響的
對方法3來說是個問題,那是因為方法3類比得不好... 方法3感覺有豬鼻子插蔥之嫌

--------------

敲code多了,文字表達能力可能不行了,偶說不對的或說不清的地方歡迎大家拍磚,3q
 

Posted by: lihun21 2005-12-28 19:27
做個記號先
學習一下
現在還沒有用到這麼深的許可權系統
我現在只有三種許可權的使用者,所以還沒有考慮那麼多
超級管理員->普通管理員->普通使用者
我想,我用的是這種模式
使用者+許可權 

Posted by: wwccss 2005-12-28 20:06
樓主的文章不錯。Donyad兄分析的也很有水平。  

Posted by: cozo 2005-12-28 20:10
這種東西只要一種方法就可以了。
我就只使用第一種。 

Posted by: bitQ 2005-12-28 21:47
這個方法我有看到過~~~


用二進位表示許可權,不會互相影響,期待做個涉及到這個的項目

高手就是高手~~` 

Posted by: BinzyWu 2005-12-28 22:01
具體怎麼標記許可權 這個較無所謂
一般的系統
RBAC是已經夠用的.

一般Access Controller有3種
user based
group based
role based

RBAC有成熟的理論基礎, 你可以搜尋以下, 能搜到很多論文.

但如果不是一般的應用系統, 那麼許可權系統可能設計需要較為特別. 這裡只有普遍理論, 未必有普遍方法.

Posted by: terpomo 2005-12-29 00:31
學習了 

Posted by: bleakwind 2005-12-29 01:14
我比較落後,我是將每個人的許可權組成的數組序列化放入資料庫。。。
每次載入頁面初始化出來。。。 

Posted by: nameless 2005-12-29 08:51
見過一個用方法3做的許可權判斷,操作很方便,也很靈活

欄目許可權用的直接把欄目標識用界定符分隔串連,操作時判斷有沒有這個標識,簡單,對欄目數過多且操作員過多的時候這個資料庫效率應該不高(如果操作員能超過 10W 的話),呵呵 

Posted by: trooman 2005-12-29 11:18
QUOTE (nameless @ 2005-12-29 08:51)
見過一個用方法3做的許可權判斷,操作很方便,也很靈活

欄目許可權用的直接把欄目標識用界定符分隔串連,操作時判斷有沒有這個標識,簡單,對欄目數過多且操作員過多的時候這個資料庫效率應該不高(如果操作員能超過 10W 的話),呵呵 

是的,我也認為方法3不會比二進位的效率差,在具體使用時可以用like,str_replace等,還可以類比二進位。

那種所謂的“欄目”許可權管理,現在已經過時了,但思想還是可以沿用的,如“對應欄目”改成“對應模組”,但實現方式已經截然不同了! 

Posted by: sean.zhuo 2005-12-29 13:51
哪位大哥能給我講解一下"角色"這個概念嗎?不懂什麽叫角色. 

Posted by: KnightE 2005-12-29 14:50
1和3,本質還是一樣的吧。
1有個好處,節省空間的。LZ提到開100個許可權用來升級。不過我遇到過一個超過100個權限類別的系統,而且使用者樹較多。所以後來壓成了16進位儲存(原來還是一樣),就類似1的處理方法了。
不過3最大的好處應該在於直觀(其實如果許可權項很多的話,也不直觀了,呵呵)。

個人認為“許可權儲存和判斷的方法”其實還不是“許可權設計”的重點和痛點。我們還需要考慮其他東西。比如許可權的設計結構(RBAC/GBAC/UBAC)的選擇,比如許可權在應用系統中的使用……

我GBAC(基於組的許可權控制)用的比較多。一般的邏輯是:

組成樹型結構,使用者跟組結點

判斷許可權,從組根目錄開始往使用者所在組進行遍曆。起始許可權為“禁止”

遍曆時,子組許可權覆蓋起始許可權,直至使用者。

最後使用者權限覆蓋起始許可權。得到最終許可權碼。


雖然貌似有些繁雜,不過較靈活些。


其次談談許可權的使用。通常的做法(至少我是這麼做的),即在“所需”時,根據以上邏輯判斷某使用者相對某許可權“是否通過”,例如(亂寫的,只是想表示是在需要是進行判斷):
CODE 

// when someone posts a new topic
if ($access_controller->check($user, 'post'))
{
   // access passed
   $user->post($content);
}
else
{
   // access denied
   $sys->accessDenied();
}
 

而我一直很想嘗試的,是這樣一種許可權使用方法:即在$user執行個體出來時,已經裝配好他擁有的許可權(check once, run anywhere),例如:
CODE 

class User
{
   var $sid;
   var $name;
   var $passwd;
   var $email;
   // ...

   function __call()
   {
       // it must be a ACCESS DENIED process here
       die('no permission');
   }

   // maybe no other methods here...
}

// we need overload the User class in PHP4
// for the __call magic method
overload('User');
$user = new User();

// we need a AccessInject method to inject accesses into user object
$access_controller->access_inject($user)
// then, the user object includes its access methods...

// ok, we use the user's method directly
$user->post($content);
// if the user object includes the post method, it has the right permission...
 

隨便寫了點,沒有很仔細考慮結構和命名,希望能表達清楚我的意思。
拋磚引玉…… 

Posted by: LuciferStar 2005-12-29 17:40
做過一個表單,用法1和3儲存多選的表單資料。 

Posted by: james.liu 2006-01-05 17:10
如果是物件導向的,,傾向於小K的想法

使用者登陸時,,如果使用者名稱,密碼,什麼都對的,允許他登陸時,,執行個體化使用者資訊,包括許可權 

Posted by: gudai 2006-01-11 16:06
許可權設計。頭疼的問題。 


         來源:http://club.phpe.net/index.php?act=Print&client=printer&f=2&t=11828

 



相關文章

Cloud Intelligence Leading the Digital Future

Alibaba Cloud ACtivate Online Conference, Nov. 20th & 21st, 2019 (UTC+08)

Register Now >

Starter Package

SSD Cloud server and data transfer for only $2.50 a month

Get Started >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。