a亚洲精品_精品国产91乱码一区二区三区_亚洲精品在线免费观看视频_欧美日韩亚洲国产综合_久久久久久久久久久成人_在线区

首頁 > 學院 > 邏輯算法 > 正文

權限設計及算法(PHPE)

2024-09-08 23:18:44
字體:
來源:轉載
供稿:網友

權限設計

大概有這幾種模式:
用戶+組+角色+權限
用戶+組+權限
用戶+角色+權限
用戶+權限


最近看了別人的設計方法,大多以“整數”來表示權限值,如添加、瀏覽、刪除和修改,分別用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

 

 

 

菜鳥學堂:
發表評論 共有條評論
用戶名: 密碼:
驗證碼: 匿名發表
主站蜘蛛池模板: 综合久久综合 | 日韩精品一区二区三区视频播放 | 成人av网站在线观看 | 国产亚洲欧美一区二区三区 | 国产成人午夜视频 | 国产精品一区二区三区视频网站 | 精品无人乱码一区二区三区 | 亚洲h视频 | 一区视频 | 久久91| 成人黄网在线观看 | 精品视频一区二区 | 成人国产一区 | 日韩精品一区二区三区中文在线 | 日韩高清国产一区在线 | 欧美精品1区 | 午夜精品久久久久久久 | 亚洲一区二区免费在线观看 | 久草 在线 | 青草av在线| 久久三区 | 黄a网站| 成人性视频在线 | 毛片com | 久久久久久一区二区 | 国产日本亚洲欧美 | 亚洲精品永久免费 | 日本涩涩视频 | se69色成人网wwwsex | 亚洲国产精品一区二区三区 | 欧美精品欧美精品系列 | 日韩大片免费看 | 久久精品国产久精国产 | 91精品国产一区二区 | av免费在线播放 | 中文字幕高清视频 | 91精品国产91久久综合桃花 | 国产免费一区二区三区 | 精品亚洲永久免费精品 | 日韩在线欧美 | 亚洲精品一区二区三区麻豆 |