|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
大家可以自己去看一看.可以说看得想呕吐.以前有次下了个动网来看.里面连基本内置函数的保护措施(函数没防御性)都没有.难怪经常补这个补那个了.可能现在.NET版会好点吧计划凡是触及多用户分歧权限的收集大概单机程序,城市有权限办理的成绩,对照凸起的是MIS体系。
上面我要说的是MIS体系权限办理的数据库计划及完成,固然,这些思绪也能够推行开来使用,好比说在BBS顶用来办理分歧级其余用户权限。
权限计划一般包含数据库计划、使用程序接口(API)计划、程序完成三个部分。
这三个部分互相依存,密不成分,要完成完美的权限办理系统,必需思索到每个环节可行性与庞大水平乃至实行效力。
我们将权限分类,起首是针对数据存取的权限,一般有录进、扫瞄、修正、删除四种,其次是功效,它能够包含比方统计等一切非间接数据存取操纵,别的,我们还大概对一些关头数据表某些字段的存取举行限定。除此,我想不出另有别的品种的权限种别。
完美的权限计划应当具有充实的可扩大性,也就是说,体系增添了新的别的功效不该该对全部权限办理系统带来较年夜的变更,要到达这个目标,起首是数据库计划公道,其次是使用程序接口标准。
我们先会商数据库计划。一般我们利用干系数据库,这里不会商基于Lotus产物的权限办理。
权限表及相干内容大致能够用六个表来形貌,以下:
1脚色(即用户组)表:包含三个字段,ID,脚色名,对该脚色的形貌;
2用户表:包含三个或以上字段,ID,用户名,对该用户的形貌,别的(如地点、德律风等信息);
3脚色-用户对应表:该表纪录用户与脚色之间的对应干系,一个用户能够从属于多个脚色,一个脚色组也可具有多个用户。包含三个字段,ID,脚色ID,用户ID;
4限定内容列表:该表纪录一切必要加以权限辨别限定的数据表、功效和字段等外容及其形貌,包含三个字段,ID,称号,形貌;
5权限列表:该表纪录一切要加以把持的权限,如录进、修正、删除、实行等,也包含三个字段,ID,称号,形貌;
6权限-脚色-用户对应表:一样平常情形下,我们对脚色/用户所具有的权限做以下划定,脚色具有明令同意的权限,别的一概克制,用户承继所属脚色的全体权限,在此局限内的权限除明令克制外全体同意,局限外权限除明令同意外全体克制。该表的计划是权限办理的重点,计划的思绪也良多,能够说半斤八两,不克不及生吞活剥说某种办法好。对此,我的意见是就团体情形,找本人以为符合能办理成绩的用。
先说第一种也是最简单了解的办法,计划五个字段:ID,限定内容ID,权限ID,脚色/用户范例(布尔型字段,用来形貌一笔记录纪录的是脚色权限仍是用户权限),脚色/用户ID,权限范例(布尔型字段,用来形貌一笔记录暗示同意仍是克制)
好了,有这六个表,依据表六,我们就能够晓得某个脚色/用户究竟具有/克制某种权限。
大概说,这么计划已充足了,我们完整完成了所必要的功效:能够对脚色和用户分离举行权限制制,也具有相称的可扩大性,好比说增添了新功效,我们只必要增加一条大概几笔记录就能够,同时使用程序接口也不必修改,具有相称的可行性。可是,在程序完成的过程当中,我们发明,利用这类办法并非非常迷信,比方扫瞄某个用户所具有的权限时,必要对数据库举行屡次(乃至是递回)查询,极不便利。因而我们必要想别的的举措。利用过Unix体系的人们都晓得,Unix文件体系将对文件的操纵权限分为三种:读、写和实行,分离用1、2、4三个代码标识,对用户同时具有读写权限的文件被纪录为3,即1+2。我们也能够用相似的举措来办理这个成绩。开端的设法是修正权限列表,到场一个字段:标识码,比方,我们能够将录进权限标识为1,扫瞄权限标识为2,修正权限标识为4,删除权限标识为8,实行权限标识为16,如许,我们经由过程权限累加的举措就能够容易的将底本要分为几笔记录形貌的权限放在一同了,比方,假定某用户ID为1,库存表对应的限定内容ID为2,同时划定脚色范例为0、用户范例为1,我们就能够将该用户具有录进、扫瞄、修正、删除库存表的权限形貌为:2,15,1,1。
的确很复杂,不是吗?乃至另有更过激的举措,将限定内容列表也加上一列,界说好标识码,如许,我们乃至能够用复杂的一笔记录形貌某个用户具有的对全体内容所具有的全体权限了。固然,如许做的条件是限定内容数目对照小,否则,呵呵,2的n次方递增起来但是数目惊人,不简单剖析的。
从外表上看,上述办法足以到达完成功效、简化数据库计划及完成的庞大度这个目标,但如许做有个坏处,我们所触及的权限列表不是互相自力而是相互依附的,好比说修正权限,实际上是包括扫瞄权限的,比方,我们大概只是复杂的设置用户对库存表存取的权限值为录进+修正+删除(1+4+8=13),但现实上,该用户具有(1+2+4+8=15)的权限,也就是说,在这类计划中,13=15。因而当我们挪用API扣问某用户是不是具有扫瞄权限时,就必需判别该用户是不是具有对该数据表的修正权限,因而,假如不克不及在程序中固化权限之间的包括干系,就不克不及使用使用程序接口复杂的做出判别。但这与我们的目标“充实的可扩大性”冲突。
这个成绩怎样办理?我想到了别的一种设置标识码的办法,那就是使用素数。我们无妨将录进、扫瞄、修正、删除、实行的基础标记码定为2,3,5,7,11,当碰到权限相互包括的时分,我们将它的标识码设定为两个(或多个)基础标记码的乘积,比方,能够将“修正”功效的标记码定为3*5=15,然后将一切的权限相乘,就失掉了我们必要的终极权限标识值。如许,我们在扣问用户是不是具有某项权限的时分,只必要将终极的值分化成质因子,比方,我们能够界说一个用户具有录进+修正+删除库存表的权限为2*15*7=2*3*5*7,即暗示,该用户具有了对库存表录进+扫瞄+修正+删除权限。
固然,对权限列表我们利用上述办法的条件是权限列表纪录条数不会太多而且干系不是非常庞大,不然,光是剖析权限代码就要呆板忽悠半宿:)
我但愿以上的剖析是准确且无效的(现实上,我也用这些的办法在不止一套体系中完成),但不管怎样,我以为云云完成权限办理,只是思索了数据库计划和使用程序接口两部份内容,关于完成,仍是显得很费力。因而,我恳请有过相似计划、完成履历的同道们提出建立性的定见和修正倡议。
</p>ASP由于使用了COM组件所以它会变的十分强大,但是这样的强大由于WindowsNT系统最初的设计问题而会引发大量的安全问题。只要在这样的组件或是操作中一不注意,哪么外部攻击就可以取得相当高的权限而导致网站瘫痪或者数据丢失; |
|