`
pavel
  • 浏览: 916353 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

关于权限设计

阅读更多

权限设计通常包括数据库设计、应用程序接口(API)设计、程序实现三个部分。

这三个部分相互依存,密不可分,要实现完善的权限管理体系,必须考虑到每一个环节可行性与复杂程度甚至执行效率。

我们将权限分类,首先是针对数据存取的权限,通常有录入、浏览、修改、删除四种,其次是功能,它可以包括例如统计等所有非直接数据存取操作,另外,我们还可能对一些关键数据表某些字段的存取进行限制。除此,我想不出还有另外种类的权限类别。

完善的权限设计应该具有充分的可扩展性,也就是说,系统增加了新的其它功能不应该对整个权限管理体系带来较大的变化,要达到这个目的,首先是数据库设计合理,其次是应用程序接口规范。

我们先讨论数据库设计。通常我们使用关系数据库

 

权限表及相关内容大体可以用六个表来描述,如下:
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,即表示,该用户具有了对库存表录入+浏览+修改+删除权限。

分享到:
评论

相关推荐

    关于权限设计的探讨.pdf

    关于权限设计的探讨.pdf关于权限设计的探讨.pdf关于权限设计的探讨.pdf关于权限设计的探讨.pdf关于权限设计的探讨.pdf

    J2EE综合--关于权限设计的详细探讨

    权限设计通常包括数据库设计、应用程序接口(API)设计、程序实现三个部分。 这三个部分相互依存,密不可分,要实现完善的权限治理体系,必须考虑到每一个环节可行性与复杂程度甚至执行效率。 我们将权限分类,首先...

    一个权限设计教程(java)

    这是一个找到一篇关于权限设计的教程,写的很好,但是发现给出的代码,有些地方可能有笔误。贴出来供大家和我一起学习。 首先,设置三种要素:用户、群组、角色。 用户为登录用,对应到人。群组对应为用户的集合,是...

    权限设计讲解资料——收集了大部分权限设计资料

    收集了很多关于权限设计的好文章,比较全面,对于研究权限的朋友来说,绝对是非常好的资料

    权限设计与数据库

    关于权限设计的讲解,从简单到复杂分组,个人觉得很不错

    OA系统数据库权限设计思路及数据库

    花了一天时间研究一篇网上关于OA系统权限设计的文档,按照文档自己手动创建了数据库,附件包括文档跟数据库,有想要了解的同学可以下载!tb_User:用户信息基本表; tb_Department:部门表; tb_Company:公司表; ...

    关于用户权限的数据库设计

    经典的数据库表设计,基于基本权限功能的设计。

    security第三版

    关于权限设计这一块,看项目需要...你可以设计得更细分..设计更多的表来区分权限..中心思想类似于我上面说的.. 项目里面以及配套了sql语句. admin用户可以访问全部页面,tinys用户只可以访问index页面.. login没设置...

    关于系统后台的用户权限设计与思考.docx

    关于系统后台的用户权限设计与思考.docx

    角色用户权限DB设计

    一直想整理一篇关于用户角色权限的设计,这几天通过网上资料和自己实际工作中运用到的资源把用户角色权限的数据库表设计出来。 基础表有3张: 角色表--用来记录角色名称 用户表--用来记录登录用户名称和登录密码 ...

    权限设计数据库实例

    最近做项目要做权限,所以在网上看了很多关于权限的设计,发现这方面在设计合理的资料实在找到不多,于是把找到的资料整理了一份,希望对想学习权限设计或编写的朋友有用。

    用户登录与权限设计delphi

    关于登录框的设计 不同用户拥有不同的权限,登录后有不同的功能

    jive.chm

    13 JDBC性能优化技巧 <br> 权限设计 1 权限系统概要 2 关于权限设计方面的问题 3 关于用户角色权限管理一点想法 4 关于权限系统的设计 <br> 缓存系统 1 ...

    asp.net知识库

    深入剖析ASP.NET组件设计]一书第三章关于ASP.NET运行原理讲述的补白 asp.net 运行机制初探(httpModule加载) 利用反射来查看对象中的私有变量 关于反射中创建类型实例的两种方法 ASP.Net应用程序的多进程模型 NET委托...

    数据库权限管理表设计的文章

    一篇关于数据库权限表设计的文章,浅显易懂,值得一看.

    StandardMisSystem后台权限管理平台设计方案

    关于Javajsp页面的权限设计方面的知识,多多传播好的知识。

    通用权限管理设计篇

    偶然看到的一个关于如何设计一个通用权限控制的数据库结构

    数据库权限设计与实现.doc

    关于设计 借助NoahWeb的动作编程理念,在设计阶段,系统设计人员无须考虑程序结构的设计 ,而是从程序流程以及数据库结构开始入手。为了实现需求,数据库的设计可谓及其重 要,无论是"组"操作的概念,还是整套权限...

Global site tag (gtag.js) - Google Analytics