110,538
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
ghosthjt 2004-11-08
- 打赏
- 举报
有一些权限还要限制对记录的访问，比如，某一个用户不能访问部门为财务部的数据，但是有的用户可以访问，这样的权限怎么设计比较好呢？？
emicamel 2004-11-08
- 打赏
- 举报
关注
elite2018 2004-11-07
- 打赏
- 举报
refer to this :
关于权限设计的探讨
但凡涉及多用户不同权限的网络或者单机程序，都会有权限管理的问题，比较突出的是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，即表示，该用户具有了对库存表录入+浏览+修改+删除权限。
当然，对权限列表我们使用上述方法的前提是权限列表记录条数不会太多并且关系不是十分复杂，否则，光是解析权限代码就要机器忽悠半宿：）
我希望以上的分析是正确且有效的（事实上，我也用这些的方法在不止一套系统中实现），但无论如何，我觉得如此实现权限管理，只是考虑了数据库设计和应用程序接口两部分内容，对于实现，还是显得很费劲。因此，我恳请有过类似设计、实现经验的同志们提出建设性的意见和修改建议。
关于权限设计的探讨
但凡涉及多用户不同权限的网络或者单机程序，都会有权限管理的问题，比较突出的是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，即表示，该用户具有了对库存表录入+浏览+修改+删除权限。
当然，对权限列表我们使用上述方法的前提是权限列表记录条数不会太多并且关系不是十分复杂，否则，光是解析权限代码就要机器忽悠半宿：）
我希望以上的分析是正确且有效的（事实上，我也用这些的方法在不止一套系统中实现），但无论如何，我觉得如此实现权限管理，只是考虑了数据库设计和应用程序接口两部分内容，对于实现，还是显得很费劲。因此，我恳请有过类似设计、实现经验的同志们提出建设性的意见和修改建议。
Uncommon 2004-11-07
- 打赏
- 举报
一份远程办公系统的方案
http://www.uml.org.cn/yyal/yszdbg.htm
http://www.uml.org.cn/yyal/yszdbg.htm
Uncommon 2004-11-07
- 打赏
- 举报
http://www.superdesign.com.cn/info.htm
http://www.sdili.edu.cn/keyan/jsjcg/3.htm
http://www.sdili.edu.cn/keyan/jsjcg/3.htm
timiil 2004-11-07
- 打赏
- 举报
偶正在研究一个商业第三方的.net 权限系统，但不是基于流程的，是基于资源的，就是RBAC。
zhongwanli 2004-11-07
- 打赏
- 举报
大家看看有没有什么现成的吧
woff 2004-11-07
- 打赏
- 举报
DING
aicode 2004-11-07
- 打赏
- 举报
看看RBAC.
webserv2 2004-11-07
- 打赏
- 举报
学习一下
深山老翁 2004-11-07
- 打赏
- 举报
学习;)
hnhl 2004-11-07
- 打赏
- 举报
redbb(....Dotneter....Reloading ...) 讲的很好....
timiil 2004-11-07
- 打赏
- 举报
楼主要现成权限的实现还是要现成的文档?
xiaoslong 2004-11-07
- 打赏
- 举报
帮你顶
zhongwanli 2004-11-07
- 打赏
- 举报
我再找找吧,大家继续....
egxsun 2004-11-07
- 打赏
- 举报
mark
hsb0307 2004-11-07
- 打赏
- 举报
到 J道 上搜一下，有过于自定义流程的权限设计。
zhongwanli 2004-11-07
- 打赏
- 举报
不管怎样,能踊跃发言,就是好同志
TKS!
TKS!
river723 2004-11-06
- 打赏
- 举报
可以考虑用代理模式,但是可能造成类的膨胀,主要看你的操作类是否很多.
luluso 2004-11-06
- 打赏
- 举报
mark.
加载更多回复（3）
