关于权限设计的探讨
关于权限设计的探讨（寻求数据库设计者和开发人员的帮助）
zealberg (
冰山)
2003-04-13 09:20:35 在
企业开发 /
企业信息化 提问
关于权限设计的探讨
但凡涉及多用户不同权限的网络或者单机程序，都会有权限管理的问题，比较突出的是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，即表示，该用户具有了对库存表录入+浏览+修改+删除权限。
当然，对权限列表我们使用上述方法的前提是权限列表记录条数不会太多并且关系不是十分复杂，否则，光是解析权限代码就要机器忽悠半宿：）
我希望以上的分析是正确且有效的（事实上，我也用这些的方法在不止一套系统中实现），但无论如何，我觉得如此实现权限管理，只是考虑了数据库设计和应用程序接口两部分内容，对于实现，还是显得很费劲。因此，我恳请有过类似设计、实现经验的同志们提出建设性的意见和修改建议。
另外，关于数据库设计的思路还有使用二维表的，这将在以后的时间里讨论，关于应用程序接口的设计和实现我也将在利用另外篇幅和大家共同探讨，代码将用类C语法实现（我不喜欢pascal，抱歉）
欢迎朋友们和我联系，mailto:[email protected]，也欢迎访问我和另外一位朋友共同建设的网站：http://www.91search.com，那里将有一个音乐搜索的工具软件提供下载。
问题点数：
100、回复次数：
120
1楼
zealberg (
冰山) 回复于
2003-04-13 09:21:27 得分
0
另外，有朋友提到：
权限设计需求：
1、用以实现对界面对象（如菜单、按钮）的权限控制。简称对象级权限
2、用以实现对数据能否被某一个用户修改、删除的权限控制。建成数据级权限
对象级权限基本上大家都实现过，数据级权限比较特殊，它能够实现数据的权限分配
例如：A用户可以将其产生的数据分配给B用户修改，给C用户删除的权限。
数据级权限的要点就是要在表中增加一个字段用以保存数据所有者的用户标识。
我的想法是这样：
数据级权限的管理和对象权限有比较大的区别，它不容易使用一条语句精确的描述，Notes的做法是保存每个文档的所有者标识，在关系型数据库中也可以使用相同（或者类似）的办法解决，但情况要复杂一些。
如果要实现对单条数据的存取控制，恐怕只能用流程来实现，这种手段在OA系统中比较常见，比如将A写的某个公文文档移交给B审批，这时B获得的只是对所有者A某一个而不是所有文档的审批权限。虽然也是赋予了B某种权限，但事实上这不属于上文所讨论的权限管理范围，而只是业务流程。
但是我们考虑，在非公文流程的大部分系统中，只是简单的设定：用户B具有对所有者A的文档具有修改权限，而这种定义，是可以在上文描述的数据库进行描述并实现的。
事实上，在关系型数据库中，要对某个用户对表的存取权限精确到记录是不可能的，这只能在程序中使用聪明巧妙或者笨办法解决，当然，与之相关的是业务流程的设计。很多OA系统自称能自定义流程，大体也就是能通过巧妙的数据库设计，将流程运作的全过程记录在数据库中。
基于Lotus的OA系统理论上可以定义某个用户对某个文档的存取权限，但实际操作中，为了减轻开发人员的负担，都只是定义了角色对某个数据库的存取权限，而将剩下的内容交由前端控制，这和我们在ASP程序中习惯使用SA登录SQL Server是一样的。
业务流程的实现方法本质上和操作权限无关，它将是另外一个讨论话题。
以上只是个人浅见，请大家批评指正！
2楼
blueshrimp (
下着沙-软件民工) 回复于
2003-04-15 11:14:52 得分
0
好文
3楼
(
) 回复于
2003-04-15 11:18:48 得分
0
nice ,收藏
4楼
(
) 回复于
2003-04-15 11:30:17 得分
0
re
5楼
SW515 (
孙五) 回复于
2003-04-15 11:31:00 得分
0
呵呵～
我有话要说～
6楼
yao_yuan (
逍遥子) 回复于
2003-04-15 11:56:56 得分
2
我们原来也这么干，后来发觉太麻烦了，增加、查询、修改、删除组合起来就有15种之多。所以后来干脆在菜单上把增加、查询、修改、删除功能分开成不同的页面。反而好办些。
7楼
win32c (
清茶+浓咖啡=C#) 回复于
2003-04-15 12:02:29 得分
0
侃侃
8楼
zoufeiyy (
Fly) 回复于
2003-04-15 13:55:24 得分
5
其实我觉得用素数并不是一个很好的方法，虽然以前也曾用过，不过现在都用字串来表示了，既方便又可扩展，素数太大了可是很成问题的啊（想象一个有20个权限设置的系统）
9楼
whose (
) 回复于
2003-04-15 13:56:04 得分
2
是麻烦些，但是比较好的方法，yao_yuan的方法小系统可能可行。
10楼
yangzi520 (
天生我才必無用) 回复于
2003-04-15 15:02:59 得分
0
關注ing...
11楼
pray1997 (
pray1997) 回复于
2003-04-15 15:03:08 得分
2
用数字组成的字符串来表示，应该是很方便的，yao_yuan(逍遥子)的方法只解决了部分问题，不是个好方法
12楼
Power_X3q (
人海沉浮) 回复于
2003-04-15 15:23:35 得分
5
根据我参加多个系统涉及权限的设计，我总结了一套权限设计方案，在目前所有的权限设计当中，权限控制主要分为两个方面：1。你是否能够看到这个菜单功能；2。你是否能够处理这个菜单设计的事务功能（相对比较复杂，有按照微软的授权方式：完全控制，读，写，删除，管理……），现在大部分系统都是用菜单来控制权限的（绝大部分时候是够用了），但是我们还增加了一个基于流程事务功能上的授权。
主要有：人员表，角色表，部门表 ， 级别表 菜单表
人员角色关系表 部门角色关系表 人员部门关系表
人员菜单表， 角色菜单表，
另外还有一套工作流程授权机制表，基本上能够控制得非常理想！
13楼
litsnake1 (
litsnake) 回复于
2003-04-15 16:22:58 得分
1
to pray1997(pray1997) ( ) :
怎么样用数字组成字符串来表示啊，
1。你是怎么解决权限的包容关系的
2。你们是怎么解决人员的多角色的问题，例如：一个员工既是财务总监又是经理，就是又多种角色的人，你们是怎么解决权限问题
谢谢！！！！！！
14楼
xiaocon (
小葱) 回复于
2003-04-15 16:53:07 得分
5
如果涉及到对记录行的管理呢？如何做？
比如有一个仓库管理软件，产品有好多种，A可能管理办公用品的，B可能管理电子产品的，那么A不能处理和查看B的记录，这种权限如何实现？
15楼
SW515 (
孙五) 回复于
2003-04-15 17:05:08 得分
40
关于权限包容关系通过角色和权限掩码来实现。
///
/// 权限保护类型枚举类型。
///
public enum ProtectEnum
{
///
RevokeProtect = 0,
///
GrantProtect = 1,
///
DenyProtect = 2
}
///
/// 系统固定用户或角色枚举类型。
///
///
/// 管理员角色：16399 = 100000000001111
/// 所有者角色：16385 = 100000000000001
/// 只读者角色：16386 = 100000000000010
/// 安全员角色：16388 = 100000000000100
/// 配置员角色：16392 = 100000000001000
///
public enum FixedRoleEnum
{
///
Administrator = 1,
///
Administrators = 16399,
///
Authors = 16385,
///
Readers = 16386,
///
Security = 16388,
///
Setting = 16392
}
///
/// 系统权限枚举类型。
///
public enum PermissionEnum
{
///
FetchPermission = 1,
///
AddNewPermission = 2,
///
UpdatePermission = 4,
///
DeletePermission = 8,
///
PrintPermission = 16,
///
FlowPermission = 1024,
///
VoidPermission = 2048
}
如果用户“Popeye”对“销售出仓单[2009]”系统对象具有读写（读取＋修改＋删除＋新增）权限：（权限表定义如下TPermission）
FormID UID Permission
======= ==== ==========
2009 Popeye 1+2+4+8=15
***** 上面系统定义的默认权限肯定是不够系统使用的，那么还有一些权限（例如：报关系统中的“计算差异表”“制造申报单”等权限，就由系统再定义），其实不用太担心会不够用的，因为在一个Form中不可能会出现所有权限情况，所以，系统自定义的权限掩码可重复使用在不同的表单中。*****
建议不要把角色和用户分开两张表来存储（可参考MS-SQL Server中的sys_users表），因为在后面的权限定义表需要引用这个表的UID（其可为用户或角色，SQL中是使用UID的数值范围来区别用户与角色的，建议也如此。），版主说的角色与用户分开对待权限设置，这点我不赞成。因为角色只不过是一种用户组，其应该享用用户的权限定义范围，在其下属的角色成员（注意角色成员不同于用户或角色哦，其可以为角色也可以为用户）均默认继承其定义的权限，除非角色成员重新指派其上级角色定义的权限字。下面给出我的相关表定义：
TUser(用户或角色表)
===================
(PK)UID int NOT NULL（主键）
Name nvarchar(50) NOT NULL（唯一性约束）
FullName nvarchar(100) NULL
Description nvarchar(255) NULL
MasterNo varchar(25) NULL（注：该字段对应为员工表中的员工编号，通过该字段就可以关联知道该用户或角色所属的员工了，在企业管理系统中很有用啊！）
TMember(用户与角色关系表)
=========================
(*PK)RoleID int NOT NULL
(*PK)UserID int NOT NULL
TPermission(用户权限表)
=======================
(*PK)FormID int NOT NULL（表示系统中各个模块或表单的唯一编号）
(*PK)UserID int NOT NULL（用户或角色编号）
Protect bit NOT NULL（1：表示显示授予权限；0：表示显示拒绝权限）
Permission int NOT NULL（权限掩码和）
***** 如果哪位兄弟有意研究权限与流程定制方面的东东，相信找偶是没错的了！！！呵呵～～～ 老板，给分啊～～～～～×××××
16楼
SW515 (
孙五) 回复于
2003-04-15 17:16:32 得分
0
xiaocon(小葱) ( ) 信誉：100
如果涉及到对记录行的管理呢？如何做？
比如有一个仓库管理软件，产品有好多种，A可能管理办公用品的，B可能管理电子产品的，那么A不能处理和查看B的记录，这种权限如何实现？
====================================================
偶以为xiaocon(小葱)同志的这个问题涉及流程权限方面，既不同的用户对同一个表单下面的不同数据具有不同的权限处理能力。呵呵，如果你把记录看成Notes中的文档，不一切就很清楚了吗？？～～～ 呵呵，建议去研究一下Lotus Notes 中的Workflow流程处理的设计，我们要做得就很清楚的～～～ 呵呵，不说了，再说下去就是侵犯商业秘密了。有兴趣的去 http://www.iLOOK100.net 看看他们的产品罢，他们对权限和流程处理是单独做了一个流程权限处理平台的，透露一点是：他们的设计思路很大一部分就是参考Lotus Notes的哦～～～
闪～
17楼
SW515 (
孙五) 回复于
2003-04-15 17:16:33 得分
0
xiaocon(小葱) ( ) 信誉：100
如果涉及到对记录行的管理呢？如何做？
比如有一个仓库管理软件，产品有好多种，A可能管理办公用品的，B可能管理电子产品的，那么A不能处理和查看B的记录，这种权限如何实现？
====================================================
偶以为xiaocon(小葱)同志的这个问题涉及流程权限方面，既不同的用户对同一个表单下面的不同数据具有不同的权限处理能力。呵呵，如果你把记录看成Notes中的文档，不一切就很清楚了吗？？～～～ 呵呵，建议去研究一下Lotus Notes 中的Workflow流程处理的设计，我们要做得就很清楚的～～～ 呵呵，不说了，再说下去就是侵犯商业秘密了。有兴趣的去 http://www.iLOOK100.net 看看他们的产品罢，他们对权限和流程处理是单独做了一个流程权限处理平台的，透露一点是：他们的设计思路很大一部分就是参考Lotus Notes的哦～～～
闪～
18楼
xiaocon (
小葱) 回复于
2003-04-15 17:26:55 得分
0
回复人： SW515(孙五) ( ) 信誉：100 2003-04-15 17:16:00 得分:0
偶以为xiaocon(小葱)同志的这个问题涉及流程权限方面，既不同的用户对同一个表单下面的不同数据具有不同的权限处理能力。呵呵，如果你把记录看成Notes中的文档，不一切就很清楚了吗？？～～～ 呵呵，建议去研究一下Lotus Notes 中的Workflow流程处理的设计，我们要做得就很清楚的～～～ 呵呵，不说了，再说下去就是侵犯商业秘密了。有兴趣的去 http://www.iLOOK100.net 看看他们的产品罢，他们对权限和流程处理是单独做了一个流程权限处理平台的，透露一点是：他们的设计思路很大一部分就是参考Lotus Notes的哦～～～
闪～
====================================================
能给点思路吗？没用过Lotus Notes，我上面说的只是一个列子，还有比如记录是A建立的，一旦建立之后，可能就由B管理了（或者A与B二个人都可以管理），而如果以后B离开了，由C(或 A与C)管理了，这样的权限如何处理？
19楼
eastliangliang (
青苹果：拒绝羊皮的狼) 回复于
2003-04-15 18:06:13 得分
10
苹果有一处不明：“角色/用户类型（布尔型字段，用来描述一条记录记录的是角色权限还是用户权限）”角色权限和用户权限分别是做什么用的，两者不一样么？
在我对权限的理解中，是用户属于某个角色，角色拥有一定的权限，一个用户对一个资源有没有操作权限，看的是他当前的所属角色是否有权限，所以我感觉用户权限和角色权限在这里是统一的，或者说只有角色权限，没有用户权限。
这六张表中，前五张和冰山兄定义的一样，第六张只有简单的一个角色ID和权限ID。我是做三层结构的，所有对数据库的操作都封装到了中间层，以中间层的业务对象提供的方法作为权限，每一个方法对应一个权限ID，在每个方法中都判断用户是否有这个权限。比如：删除回复的权限ID是1001，每次调用删除回复方法时，联合查询用户名，用户所属角色和权限ID是1001的记录，如果有此记录，则进行删除。现在看来有个缺点，我把限制内容，也就是资源ID硬编码到权限ID中了，而且权限ID被硬编码到程序中了，下次改进一下。
感觉三层和两层的权限设计还是有区别的，毕竟三层中数据库不会直接暴露给客户端。所说仅供参考。
给个网址参考，还有一篇姊妹篇，找不到啦
http://www.jdon.com:81/jive/article.jsp?forum=46&thread=4110&message=438816
20楼
icecafee (
青梅) 回复于
2003-04-15 21:22:06 得分
5
我的软件是这样做的：
1.可以对用户授权也可以对用户所属组授权，而用户所属组可以有多个（用户信息中有所属组列表属性），比如“董事会”组中某成员完全也可以是“部门经理”组的成员，组与个人用户一样在用户表中可以创建，不同的是没有密码和真实姓名等信息（没有信箱等基础设施，只是身份转定义桥）；
2.所有文档属于栏目，栏目管理员对栏目具有最高权限，所有栏目权限分为：模板定义、模板审批、内容创建、内容审批；
3.浏览权限由文档的发布对象（邮件收件人或者栏目，发布到栏目的必须有该栏目发布权限，有该栏目发布权限的未必有浏览权限，比如“归档”栏目可能只有档案管理员可以看）定义，某绝密文档可能一个销售员就能看但财务经理不能看，如果对每类文档去定义，累死也不成的。
这样，当发布规章制度等一类完全公开的文档时，所有人都可以看，而内部公文则只有邮件收件人可以看并自动归档。
邮件可以有禁止转发属性，此类邮件的文本是防拷贝的。
21楼
Tomcat4 (
Tom) 回复于
2003-04-16 10:40:05 得分
0
up!
Mark!
22楼
luosidao (
螺丝刀) 回复于
2003-04-16 10:48:53 得分
0
good!
Up!
23楼
(
) 回复于
2003-04-16 12:13:37 得分
0
Top
24楼
blueshrimp (
下着沙-软件民工) 回复于
2003-04-16 14:24:44 得分
0
呵呵，都是一星级的用户，从其它版吸引过来的。
25楼
solar (
天哪,忘了我是什么时候注册的了!)(int argc, char *argv[]) 回复于
2003-04-16 14:47:45 得分
0
good
26楼
simonzone (
赏花赏月赏秋香) 回复于
2003-04-16 15:16:33 得分
0
好贴.
27楼
(
) 回复于
2003-04-16 16:17:42 得分
0
mark
28楼
hongzhen225 (
) 回复于
2003-04-16 16:31:15 得分
0
收藏一下
29楼
linlexing (
拉拉叉) 回复于
2003-04-16 17:24:12 得分
10
以上的方法与我做的项目的方法基本一致，现摘一部分的表结构，以供大家参考
create table t_workelement /*工作元素表*/
(
code varchar(20) not null, /*元素的代码，唯一*/
name varchar(50) not null UNIQUE,/*元素的名称，唯一*/
type int not null, /*类型 0-单据操作 1-报表操作 2-功能操作*/
bcode varchar(20) null, /*对应操作的单据/报表/功能的代码*/
style int null, /*单据：类型 0-查看 1-新增 2-修改 3-删除*/
/*报表：无*/
/*功能：无*/
term ntext null, /*单据：查看/修改/删除时要符合的条件,如"{$承揽合同.编号}=12/n{$承揽合同.名称}<>'afd'"*/
primary key(code)
)
go
drop table t_role
go
create table t_role /*角色表*/
(
name varchar(30) not null,
category varchar(50) null,
remark varchar(100) null,
primary key(name)
)
go
drop table t_roleelement
go
create table t_roleelement /*角色元素操作表*/
(
rname varchar(30) not null, /*角色名称*/
ecode varchar(20) not null, /*元素的代码*/
primary key(rname,ecode)
)
go
drop table t_users
go
create table t_users /*用户表*/
(
name varchar(20) not null, /*用户的名称*/
dcode varchar(20) not null, /*所属的部门*/
category varchar(50) null, /*用户的类别*/
pswd varchar(15) null, /*密码*/
primary key(name)
)
go
/*插入系统管理员*/
INSERT INTO t_users
(
name,
dcode,
category,
pswd
)
VALUES
(
'Admini',
'system',
'超级用户',
''
)
go
drop table t_userrole
go
create table t_userrole /*用户角色表*/
(
uname varchar(20) not null, /*用户名称*/
rname varchar(30) not null, /*角色的名称*/
primary key(uname,rname)
)
go
INSERT INTO t_userrole
(
uname,
rname
)
VALUES
(
'Admini',
'系统管理员'
)
go
drop table t_dept
go
create table t_dept /*部门表*/
(
code varchar(20) not null, /*部门的代码*/
name varchar(50) not null UNIQUE,/*部门的名称*/
type varchar(10) null, /*部门的类别 行政 仓库 车间*/
subtype varchar(16) null, /*子类别 成品仓库 原料仓库自定义*/
primary key(code)
)
go
/*插入系统管理部*/
INSERT INTO t_dept
(
code,
name,
type
)
VALUES
(
'system',
'系统管理部',
'行政'
)
go
30楼
SW515 (
孙五) 回复于
2003-04-16 17:27:49 得分
0
回复人： xiaocon(小葱) ( ) 信誉：100
*****************************************
能给点思路吗？没用过Lotus Notes，我上面说的只是一个列子，还有比如记录是A建立的，一旦建立之后，可能就由B管理了（或者A与B二个人都可以管理），而如果以后B离开了，由C(或 A与C)管理了，这样的权限如何处理？
========================================================================
这个其实是一种所谓角色转移的东东，如果要程序自动来处理的话，有几点概念性的问题要搞清楚：1、什么叫做某用户离开了？？？2、如何鉴别“离开”这个事件？！！！3、由谁来激发这个用户“离开”事件？？？？4、后继角色或用户如何自动接管离开角色或用户的权限？！！最后还有一点，如果离开的那个用户又突然杀个回马枪，他又该如何收回其权限，并且接受用户或角色如何放手呢？？？ 呵呵…… 看来，这个问题不简单啊～ 我无意使问题复杂化，也不想打击xiaocon(小葱)兄的信息，只是想提醒一下，如果要想把东西做好绝不是简单的事情，前期的设计比什么都重要啊！！！！呜呜～～～
我有个“野蛮”的招，就是人工来做。比如说A用户“离开”了，业务经理（反正不是我）就打个电话给系统权限管理员，告诉他把A用户的流程权限加入到继承者B和C的门下～～呵呵，这样也算一种解决方案罢～～ 笨是笨点，但是还是可以解决实际问题的～～～
呵呵…… 闪～
31楼
SW515 (
孙五) 回复于
2003-04-16 17:27:50 得分
0
回复人： xiaocon(小葱) ( ) 信誉：100
*****************************************
能给点思路吗？没用过Lotus Notes，我上面说的只是一个列子，还有比如记录是A建立的，一旦建立之后，可能就由B管理了（或者A与B二个人都可以管理），而如果以后B离开了，由C(或 A与C)管理了，这样的权限如何处理？
========================================================================
这个其实是一种所谓角色转移的东东，如果要程序自动来处理的话，有几点概念性的问题要搞清楚：1、什么叫做某用户离开了？？？2、如何鉴别“离开”这个事件？！！！3、由谁来激发这个用户“离开”事件？？？？4、后继角色或用户如何自动接管离开角色或用户的权限？！！最后还有一点，如果离开的那个用户又突然杀个回马枪，他又该如何收回其权限，并且接受用户或角色如何放手呢？？？ 呵呵…… 看来，这个问题不简单啊～ 我无意使问题复杂化，也不想打击xiaocon(小葱)兄的信息，只是想提醒一下，如果要想把东西做好绝不是简单的事情，前期的设计比什么都重要啊！！！！呜呜～～～
我有个“野蛮”的招，就是人工来做。比如说A用户“离开”了，业务经理（反正不是我）就打个电话给系统权限管理员，告诉他把A用户的流程权限加入到继承者B和C的门下～～呵呵，这样也算一种解决方案罢～～ 笨是笨点，但是还是可以解决实际问题的～～～
呵呵…… 闪～
32楼
zealberg (
冰山) 回复于
2003-04-16 19:55:19 得分
0
To： zoufeiyy(Fly)
其实我觉得用素数并不是一个很好的方法，虽然以前也曾用过，不过现在都用字串来表示了，既方便又可扩展，素数太大了可是很成问题的啊（想象一个有20个权限设置的系统）
…………………………………………………………………………………………………………
素数太大不方便操作，用字符串表示是个好办法，支持！非常感谢！——我当时怎么没想到呢？我只想用数学的方法描述了：）
33楼
zealberg (
冰山) 回复于
2003-04-16 20:06:23 得分
0
to： Power_X3q(人海沉浮)
根据我参加多个系统涉及权限的设计，我总结了一套权限设计方案，在目前所有的权限设计当中，权限控制主要分为两个方面：1。你是否能够看到这个菜单功能；2。你是否能够处理这个菜单设计的事务功能（相对比较复杂，有按照微软的授权方式：完全控制，读，写，删除，管理……），现在大部分系统都是用菜单来控制权限的（绝大部分时候是够用了），但是我们还增加了一个基于流程事务功能上的授权。
主要有：人员表，角色表，部门表 ， 级别表 菜单表
人员角色关系表 部门角色关系表 人员部门关系表
人员菜单表， 角色菜单表，
另外还有一套工作流程授权机制表，基本上能够控制得非常理想！
…………………………………………………………………………………………………………
在不同的系统中，权限设计当然可以使用不同的策略，基于菜单+流程的办法对于大多数的OA系统而言，应该是足够的。很多小型的MIS系统，甚至只使用菜单就能实现权限管理，根本没必要弄得很麻烦。
我提及的权限设计方案本质上是针对中等规模的MIS、ERP系统的，所以没有太多考虑OA系统中的流程因素。当然，要付诸实用并具有一定的通用性，还需要结合实际的案例加以改进。
34楼
zealberg (
冰山) 回复于
2003-04-16 20:19:43 得分
0
To： litsnake1(litsnake)
to pray1997(pray1997) ( ) :
怎么样用数字组成字符串来表示啊，
1。你是怎么解决权限的包容关系的
2。你们是怎么解决人员的多角色的问题，例如：一个员工既是财务总监又是经理，就是又多种角色的人，你们是怎么解决权限问题
谢谢！！！！！！
………………………………………………………………………………………………
这个问题我考虑了一下，也借鉴了一些BBS管理帖子层次的设计方法，如下：
假定录入操作的权限ID为1，浏览操作的权限ID为2，修改操作的权限ID为3，删除操作的权限ID为4
同时假定修改操作包括了浏览操作权限，删除操作包括了修改操作的权限
在表5（权限列表）中加入一个字段：权限值
那么可以设定：录入操作的权限值为1，浏览操作的权限值为2，修改操作的权限值为32，删除操作的权限值为432，这样就解决了权限包容关系
同时我们规定，各权限描述数据在表6（权限-角色-用户对应表）中存储的数据为权限值的简单累加
这样，当我们读到某用户对库存表的权限为1432（即拥有录入、删除权限）时，如果要判断他是否具有浏览权限，只要简单的查找到该字符串中是否有2便可，这种情况下，权限代码1432和12432，1232432表示的意思是一样的，读取的方式也相同。
35楼
(
) 回复于
2003-04-16 20:20:48 得分
0
gz
36楼
zealberg (
冰山) 回复于
2003-04-16 20:44:16 得分
0
To： SW515(孙五)
使用掩码实现是个不错办法，我最初甚至想用分段的掩码来区分不同的权限（类似于IP，只是不需要那么多，顶多两段就够了），但考虑到MIS系统通常使用VB语法实现，位运算不是很方便（呵呵，本人对VB不精通，或许也是很简单的），所以没有加入进来
你的代码很不错，对权限保护类型分了三种，我就只想到用两种：允许或者禁止
///
/// 权限保护类型枚举类型。
///
public enum ProtectEnum
{
///
RevokeProtect = 0,
///
GrantProtect = 1,
///
DenyProtect = 2
}
很受启发，非常感谢！
37楼
zealberg (
冰山) 回复于
2003-04-16 21:00:30 得分
0
To： eastliangliang(青苹果)(道可道，非常道)
苹果有一处不明：“角色/用户类型（布尔型字段，用来描述一条记录记录的是角色权限还是用户权限）”角色权限和用户权限分别是做什么用的，两者不一样么？
在我对权限的理解中，是用户属于某个角色，角色拥有一定的权限，一个用户对一个资源有没有操作权限，看的是他当前的所属角色是否有权限，所以我感觉用户权限和角色权限在这里是统一的，或者说只有角色权限，没有用户权限。
………………………………………………………………………………………………………………
用户是属于某个或多个角色的，例如，销售部主管通常也可以普通销售的身份进入系统，但他具有其它方面如统计的权限，比如说所有销售人员的营业额进行统计。
你可能会说，单独定义一个销售部主管的角色不就行了？但事实上，用户具有多重身份的情况是很常见的，如果某个财务人员也兼职做销售，呵呵，麻烦就大了。所以通常需要考虑用户属于多个角色的可能性。
另外，在公司的实际运行过程中，某个用户可能会具有本身所属角色组以外的权限，还拿刚才说的销售部主管为例子，如果我们没有将销售部主管定义为单独的角色，而只有销售人员这个角色，而总经理有统计所有销售人员营业额的权限，当然，他还有另外的权限。当我们要定义某个销售人员是销售主管时，只需要将他的权限加上一条“允许对所有销售人员的营业额进行统计”就够了。
关于对某个用户禁止某项权限，思路也是一样的。
38楼
zealberg (
冰山) 回复于
2003-04-16 21:14:43 得分
0
To： SW515(孙五)
这个其实是一种所谓角色转移的东东，如果要程序自动来处理的话，有几点概念性的问题要搞清楚：1、什么叫做某用户离开了？？？2、如何鉴别“离开”这个事件？！！！3、由谁来激发这个用户“离开”事件？？？？4、后继角色或用户如何自动接管离开角色或用户的权限？！！最后还有一点，如果离开的那个用户又突然杀个回马枪，他又该如何收回其权限，并且接受用户或角色如何放手呢？？？ 呵呵…… 看来，这个问题不简单啊～ 我无意使问题复杂化，也不想打击xiaocon(小葱)兄的信息，只是想提醒一下，如果要想把东西做好绝不是简单的事情，前期的设计比什么都重要啊！！！！呜呜～～～
我有个“野蛮”的招，就是人工来做。比如说A用户“离开”了，业务经理（反正不是我）就打个电话给系统权限管理员，告诉他把A用户的流程权限加入到继承者B和C的门下～～呵呵，这样也算一种解决方案罢～～ 笨是笨点，但是还是可以解决实际问题的～～～
呵呵…… 闪～
……………………………………………………………………………………………………………………
这玩意和电话的呼叫转移差不多，电话使用的办法是向电信局申报，我们也可以这样解决……
打电话是一种办法，发个短信也行啊……于是可以设计一个这样的模块：根据用户的请求自动更改相应权限，想想应该是不复杂的，只是好像需要在程序中写死……
对了，突然想起，呼叫转移还有一个功能：无人应答转移，这个就不好弄了，比如规定“A三天内未审批该文档则自动转交到B”，不容易判断“三天”这个日期，自动触发……，高手们想想办法
39楼
beihua (
水鸟) 回复于
2003-04-16 21:55:01 得分
2
“人员的操作权限只能由他的上级领导来分配,而不是由系统管理员一个人来给所有人分配权限"
这种系统权限很容易引起管理的混乱，设计也比较麻烦。
但是做项目有时遇到客户单位提出这种权限控制要求。
我用JAVA,谁能详细谈谈这种权限系统应该怎样设计?能否给出一个清晰的权限设计框架？
谢谢！
40楼
Power_X3q (
人海沉浮) 回复于
2003-04-17 09:02:21 得分
2
其实我觉得权限处理还有一种：授权，和代理的说法，那就是：某某将自己的权限授权给别人去用，也就是别人代理自己的业务或权限。不知道大家对此有什么好的想法，应该碰到过吧，只是不一定很常见！
41楼
beihua (
水鸟) 回复于
2003-04-17 09:19:12 得分
0
高手们能给解答一下吗？
“人员的操作权限只能由他的上级领导来分配,而不是由系统管理员一个人来给所有人分配权限"
这种系统权限很容易引起管理的混乱，设计也比较麻烦。
但是做项目有时遇到客户单位提出这种权限控制要求。
我用JAVA+MSQSQL,谁能详细谈谈这种权限系统应该怎样设计?能否给出一个清晰的权限设计框架？
谢谢！
42楼
zealberg (
冰山) 回复于
2003-04-17 09:56:52 得分
0
TO： beihua(白话)
“人员的操作权限只能由他的上级领导来分配,而不是由系统管理员一个人来给所有人分配权限"
这种系统权限很容易引起管理的混乱，设计也比较麻烦。
但是做项目有时遇到客户单位提出这种权限控制要求。
我用JAVA,谁能详细谈谈这种权限系统应该怎样设计?能否给出一个清晰的权限设计框架？
谢谢！
…………………………………………………………………………………………
对于权限的权限设计，复杂，复杂……俺不知
43楼
rengm (
轻舟已过) 回复于
2003-04-17 10:47:43 得分
0
up
44楼
clacklin (
海风) 回复于
2003-04-17 11:47:39 得分
5
路过中…………上面的我没细看，下次再仔细看看。下面是我的一点见解。
在现实中，权限控制包括一个用户所担任岗位、角色，岗位与角色的有点区别。岗位是专门负责某方面的一个角色，如：一个局下面有好几个分局，相应的设立了多个分局长，这个“分局长”就是角色，岗位就是：××局分局长。这样，某个岗位的人看到的数据就与别的岗位的应该有所区别。这就是xiaocon(小葱)所说的“
如果涉及到对记录行的管理呢？如何做？
比如有一个仓库管理软件，产品有好多种，A可能管理办公用品的，B可能管理电子产品的，那么A不能处理和查看B的记录，这种权限如何实现？”
也就是说，Ａ与Ｂ的岗位责任区不一样。这里就新提出一个责任区的概念。责任区与人无关，只与岗位有关系。所以：岗位＝角色＋责任区。而角色权限控制是对该角色能对哪些程序业务模块进行操作的控制。只要对一个用户赋于特定的岗位（当然是可以多个岗位的），就可以控制该用户的系统功能使用权限、数据查询范围。
这样新的需要也就出来了，不同岗位的人使用同一模块时，所拥有的权限是不一样的。（这里先假设该模块有如下功能：增加删除修改提交审批查询）这也是上面大家所说的对象权限。根据我这里所实现的整个权限体系，可以自由配置某个角色对某模块里某个表的对象权限；可以自由配置该模块哪个字段是否只读。这样，在一个流程里，只需做一个模块，就可以让不同的岗位的人进行相应的数据流操作：开单人只能进行开单、提交，审核人只能进行审核、提交、退单，不能删除修改。其它的流程控制就不属于这里所讨论范围了。（具体如何实现请不要问我了，我现在难得上一次ＣＳＤＮ的）
这样，权限控制能做到对象级、数据级、字段级。所有的控制全部可以由系统管理员进行配置，程序开发时不必针对不同的权限要求来另外开发相应的模块。
（讲得很零乱，大家别见怪：Ｐ）
45楼
Martin2002 (
) 回复于
2003-04-17 12:56:11 得分
1
我这里有一个疑问,如果一个用户有了增加权限,那么是否有修改权限,有了修改权限是不是也就等于开了增加权限呢?
我对这两个问题看法是,有了增加权限未必会有修改,但是有了修改,隐含者这个人有了增加的权限,尽管在数据库看来,并没有增加一条记录,但是用户完全了频繁修改记录,而造成数据的更新.特别是对一些MIS系统,比如说用户需要发布信息到控制中心,但是发一条信息需要1毛钱,这个时候用户可以增加一条信息,然后在当天内不停的对这条信息进行修改,这样对控制中心是一种损失,但是如果禁止用户的修改,这也是不可能的事情.
不知道大家对这个观点有什么看法
46楼
luck2050 (
fjx) 回复于
2003-04-17 13:32:11 得分
2
to martin2002:
对于这种情况是发布了就不可能修改，修改只限于发布之前
47楼
andyx (
) 回复于
2003-04-17 15:30:13 得分
0
To： SW515(孙五) 和其他高手
你的代码对权限保护类型分了三种，
///
/// 权限保护类型枚举类型。
///
public enum ProtectEnum
{
///
RevokeProtect = 0,
///
GrantProtect = 1,
///
DenyProtect = 2
}
请问在什么情况下设定为 “撤回权限保护类型” ？
48楼
beihua (
水鸟) 回复于
2003-04-17 15:30:59 得分
0
zealberg(冰山):
看来你是高手了。
能不能回答一下我的问题？
如果权限设计的不好，整个系统就有可能返工。
急！！！！！！！！！！！
49楼
eastliangliang (
青苹果：拒绝羊皮的狼) 回复于
2003-04-17 18:00:15 得分
0
to冰山兄：用户当然是可以属于多个角色的，但是要求每次登录只用一个角色不行吗。你可以按部门划分开，你想管理财务，就登录财务的部门；你想去管销售，那再登录销售的部门；如果想同时做两件事，恩，要么麻烦点，换角色，要么来个角色继承（临时想的，没想怎么实现之）
50楼
litsnake1 (
litsnake) 回复于
2003-04-18 09:45:16 得分
0
我觉得象楼上讲的当用户是属于多角色的时候，我以前想的是用角色继承的方法，
但是不知道还有没有更好的方法呢
51楼
lalasang (
蓝色火焰) 回复于
2003-04-18 12:49:39 得分
0
浏览、录入、修改、删除????
后三种权限有什么区别？？？
数据库权限的特点和MIS系统中权限的特点是不一样的！！
52楼
zealberg (
冰山) 回复于
2003-04-18 13:28:56 得分
0
To： eastliangliang(青苹果)(道可道，非常道)
用户当然是可以属于多个角色的，但是要求每次登录只用一个角色不行吗。你可以按部门划分开，你想管理财务，就登录财务的部门；你想去管销售，那再登录销售的部门；如果想同时做两件事，恩，要么麻烦点，换角色，要么来个角色继承（临时想的，没想怎么实现之）
……………………………………………………………………………………………………………………
一个用户在系统中有几个账号，要做什么事，用相应的账号登录就可以了。只要能用户接受，就可以用这种方法实现。
跟这个类似的一个办法，不需要添加几个账号。就和网易通行证一样，进入系统后可以选择各种不同的服务（功能）。这个比较容易在B/S系统中实现，C/S模式的可以参考网易泡泡。
关于角色继承，依我看一般的系统中没必要弄得这么复杂，可以使用别的替代解决方法，比如提供增加角色的功能，然后定义角色的权限而不是设置这个角色属于其它角色组。
53楼
qxm (
qxm) 回复于
2003-04-18 13:43:40 得分
1
我说一下我们的方法。
权限首先分为功能层和数据层。
从功能层上说，当然包括增、删、改、查了。
从数据层上说就是某个人做操作时可以看到哪些数据，比如是总部人员，就可以查询所有办事处的数据，是办事处人，就只能查自己办事处的数据。
我们是将所有功能和对应的页面存在数据库中，有一个ID号，而每个用户的权限也会有一串号码来判断。比如一个功能的ID号为30，对应于test.jsp，则这个用户权限代号的第30位如果为0就表示他无此权限，如为1则有。这种方式对维护每个人的权限非常方便，只要将所有功能列出，并打勾选择。
但不足的就是进没个页面都必须要判断一下，因为要防止他直接敲每个页面的URL。虽然对开发很简单，但对系统速度会有影响。
54楼
zealberg (
冰山) 回复于
2003-04-18 14:10:11 得分
0
每个页面都判断权限我是用Session实现的，登录时建议权限数组然后存放到session中，操作速度就快多了
55楼
lizhongkun (
泛型) 回复于
2003-04-18 15:49:34 得分
0
go on!~
56楼
(
) 回复于
2003-04-18 17:59:28 得分
0
好文！
57楼
(
) 回复于
2003-04-18 18:35:17 得分
0
权限应该分类三类：
一是系统方面，主要是对模块的权限划分
二是数据库操作方面，主要是增加，修改，删除记录，
三是数据浏览，又分为两个：1数据字段的查看，是不是每个操作员都可是看到所有的字段的。2是是数据行的浏览，不是每个操作员都可以看到所有记录的，比如在工资管理中一个部门操作员就只能看到本部门人员的工资，甚至只能看到本部门什么职位以下的人员的工资。这样的话就可以把一个操作员的权限具体到一个二维表中的最基本的单位某一格。
58楼
(
) 回复于
2003-04-18 20:07:57 得分
0
ho
59楼
(
) 回复于
2003-04-18 20:48:30 得分
0
利用数据库本身的权限管理来对MIS系统进行管理，这个方法不知是否可行，有人做过吗？
60楼
(
) 回复于
2003-04-18 23:14:29 得分
0
收藏！
61楼
(
) 回复于
2003-04-19 00:15:47 得分
0
up
62楼
hpretty (
阿飞) 回复于
2003-04-19 09:32:53 得分
0
楼主说用素数，我觉得还不如用一个bit表示你的权限，解析起来简单，位数也是有足够的空间
32位整数就有31位可用，足够了吧！
1000，0000，0000，0000，0000，0000，0000，0000表示查看
0100，0000，0000，0000，0000，0000，0000，0000表示插入
0010，0000，0000，0000，0000，0000，0000，0000表示修改
.....
看是不是有这个权限
拿这个数同你取出来的数一 & 不就知道了吗？
为什么用素数，还分解因子什么的，太麻烦了吧！
63楼
hpretty (
阿飞) 回复于
2003-04-19 09:33:49 得分
0
要是再不够，可以用LONGINT来做。
64楼
beihua (
水鸟) 回复于
2003-04-19 15:08:18 得分
0
高手们能给解答一下吗？
“人员的操作权限只能由他的上级领导来分配,而不是由系统管理员一个人来给所有人分配权限"
这种系统权限很容易引起管理的混乱，设计也比较麻烦。
但是做项目有时遇到客户单位提出这种权限控制要求。
我用JAVA+MSSQL,谁能详细谈谈这种权限系统应该怎样设计?能否给出一个清晰的权限设计框架？
谢谢！
65楼
beihua (
水鸟) 回复于
2003-04-20 10:11:27 得分
0
怎么没人理我？
66楼
zealberg (
冰山) 回复于
2003-04-20 10:35:19 得分
0
To beihua(白话)
首先要解决的是如何区分某个人员的“上级领导”，当然，这个比较容易实现，给每个用户加一项“直接领导者是谁”，然后用递归的方法判断具体用户的领导和下属集。
通常情况下，只有系统管理员才能看到权限设置的界面，在你所描述的系统中，当然需要每个人都拥有自己的权限设置界面了，在这个界面中，用户只能赋予或取消他的下属集中用户不超过自身权限的权限，当然，他也能添加不超过自身权限的用户作为自己的下属（或这是下属的下属），这一点，最好由程序来控制，而不是数据库。
重要的一点就是用户不能授予其它用户超出本身权限以外的权限，这和操作系统中AddUser的思路是一致的。要实现这一点，下属的权限必定是领导人权限的子集，最高领导人（假设是总经理）必须拥有系统的所有权限，类似于超级用户。
具体到某种语言，我想实现不是什么问题，你也不是想要别人给你一段代码。
67楼
commts (
) 回复于
2003-04-20 22:35:44 得分
0
大哥们怎么才能借助系统提供的权限管理模块来进行用户权限管理呀？
比如用windown系统的可读，可写，运行，修改等
68楼
beihua (
水鸟) 回复于
2003-04-21 10:15:43 得分
0
多谢冰山兄!
69楼
(
) 回复于
2003-04-21 14:50:28 得分
0
标记一下
70楼
sungoodnews (
Microtoby) 回复于
2003-04-21 15:22:58 得分
0
好文共欣赏！
71楼
zealberg (
冰山) 回复于
2003-04-21 16:16:41 得分
0
To： hpretty(阿飞)
楼主说用素数，我觉得还不如用一个bit表示你的权限，解析起来简单，位数也是有足够的空间
32位整数就有31位可用，足够了吧！
1000，0000，0000，0000，0000，0000，0000，0000表示查看
0100，0000，0000，0000，0000，0000，0000，0000表示插入
0010，0000，0000，0000，0000，0000，0000，0000表示修改
.....
看是不是有这个权限
拿这个数同你取出来的数一 & 不就知道了吗？
为什么用素数，还分解因子什么的，太麻烦了吧！
……………………………………………………………………………………………………
我仔细考虑了你的想法，近日看了Google对命中列表（Hit Lists）数据压缩存储的方式，感觉使用素数是不合情理的方法，当然，对于权限限制内容较少的系统，也是可以用该方法解决的，它的复杂性比位操作要简单一些（分解因子的工作量其实很小，因为权限代码的因子一定包含在基本标志码列表中，只要照着除就可以了）。
但本人以为，字符串和位操作两者的实现本质上是一样的，关键在于对空间的占用和对于位操作的复杂性之间的权衡，考虑到通常MIS系统对空间占用要求不高，并且权限限制内容本身很少，用不了几个字节的地方，所以，通常情况下，还是使用字符串的好，它简要明了、操作简单，实现的具体方式可以参看前面我给litsnake1(litsnake)兄弟的回复。
72楼
quengzi (
Hades) 回复于
2003-04-21 19:50:36 得分
0
有一种华山论剑的味道！
73楼
(
) 回复于
2003-04-21 22:00:26 得分
0
不错
74楼
albert_qhd (
浪子) 回复于
2003-04-22 11:16:34 得分
0
分析的不错
75楼
richardluopeng (
罗罗) 回复于
2003-04-22 11:28:41 得分
0
关注
76楼
ideadoer (
) 回复于
2003-04-22 11:59:49 得分
0
权限的设置需按级别进行：
1、字段数据级：有些数据可编辑，有些不可。解法：设置可编辑字段
2、记录级：有些记录可查看，有些不可。解法：设置查询条件
3、表级：有些字段可看到，有些看不到。解法：设置显示字段
4、多表级：有些表可以看到，有些看不到。解法：配置表
权限范围的确定：本人、本部门(含下属部门)、本公司
用一个表来管理这些内容就行了，不必那么复杂。
77楼
SW515 (
孙五) 回复于
2003-04-22 12:51:15 得分
0
呵呵，很久没来看贴了～～～
先睡一觉先，下午再回～～～
—— 占位！
78楼
shark7823 (
魔鬼的脸蛋，天使的身材) 回复于
2003-04-22 13:06:47 得分
0
gz
79楼
ggzzkk (
啦啦啦！啦啦啦！) 回复于
2003-04-22 13:59:07 得分
0
mark
80楼
m_pDelphi (
闲人) 回复于
2003-04-22 14:29:38 得分
0
mark
mark
mark
81楼
SW515 (
孙五) 回复于
2003-04-22 19:17:39 得分
0
回复人： beihua(白话) ( ) 信誉：100 2003-4-16 21:55:01 得分:0
“人员的操作权限只能由他的上级领导来分配,而不是由系统管理员一个人来给所有人分配权限”
这种系统权限很容易引起管理的混乱，设计也比较麻烦。
但是做项目有时遇到客户单位提出这种权限控制要求。
我用JAVA,谁能详细谈谈这种权限系统应该怎样设计?能否给出一个清晰的权限设计框架？
谢谢！
==============================================================================
如果把你所认为的上级领导看作权限中的一个用户的话，那么只要将这个用户加入到安全管理员或者系统管理员固定角色中，他就具有权限定义的操作权限了。
82楼
loulanlouzhu (
桃花潭水深千尺，不及阿勇念你情) 回复于
2003-04-23 09:47:59 得分
0
请问在进行验证的时候是不是每个页面都要进行用户权限的验证!?
另外数据库该怎么设计才可能是可扩展的!?
83楼
hpretty (
阿飞) 回复于
2003-04-23 11:25:40 得分
0
回复人： beihua(白话) ( ) 信誉：100 2003-4-16 21:55:01 得分:0
“人员的操作权限只能由他的上级领导来分配,而不是由系统管理员一个人来给所有人分配权限”
这种系统权限很容易引起管理的混乱，设计也比较麻烦。
但是做项目有时遇到客户单位提出这种权限控制要求。
我用JAVA,谁能详细谈谈这种权限系统应该怎样设计?能否给出一个清晰的权限设计框架？
谢谢！
==============================================================================
用“角色”就可以实际的呀，下级要可以授权是不！
给他来一个“分管理员”（只能管自己所在部门及下级部门的权限）不就行了吗？
84楼
restart2001 (
...凤凰一辉...) 回复于
2003-04-23 14:13:49 得分
0
mark
85楼
fangke (
咸菜) 回复于
2003-04-23 14:39:13 得分
0
不错,收藏
86楼
(
) 回复于
2003-04-23 15:04:50 得分
0
不知道各位有没有使用过win2000的AD Server来结合MIS设计权限部分的管理呢？
87楼
zealberg (
冰山) 回复于
2003-04-24 15:32:05 得分
0
To： events(兵马俑)
不知道各位有没有使用过win2000的AD Server来结合MIS设计权限部分的管理呢？
……………………………………………………………………………………………………
这个问题bucher先生的做法是：
我说一个与数据库无关的安全解决方案
我是一个比较喜欢偷懒的人，写过一套类似于楼主所说的权限系统，但是发觉在用户组的权限继承方面存在一个极大的麻烦，而当用户同时属于两个组的时候，权限的交集计算非常麻烦。还有权限的委派和用户权限的临时提升也是一个很烦人的事情。于是就放弃了那套系统。
我发觉Windows2000的AD权限系统非常不错，于是动起了这个脑筋，最后发掘“组策略”可以实现我的想法。组策略支持继承和权限交集，而且使用也非常方便。于是研究了一下其2次开发原理，使用了注册表策略实现了我公司MIS系统的权限，可以控制到任意应用程序角度（完全取决于软件开发者），而且配置相当方便（使用AD的用户、用户组管理器）。
其实AD的注册表策略非常简单，充其量就是其用户权限的延伸，我们自定义了新的权限。AD负责对其进行管理和计算，然后把最终的结果写入用户计算机的注册表的一个受保护的段内。该内容对于用户只读。对于客户端程序，只需要判断注册表的键值即可。
其实注册表策略是一个非常简单的权限系统，唯一要做的就是写一个配置文件告诉
AD需要写入那些注册表项。在客户端只要一个小小的DLL用于读取这段注册表数据
即可。
你可以再Windows2000 server 的帮助文件中搜索“创建自定义 .adm 文件”，相
信可以给你一些启发。
………………………………………………………………………………………………………………
我看了.adm文件的写法，也看了一下MMC程序的特征，解决方案确实不错，值得借鉴！
88楼
zealberg (
冰山) 回复于
2003-04-24 15:33:36 得分
0
请参看的末尾部分
http://expert.csdn.net/Expert/topic/1645/1645811.xml?temp=.4102747
后面内容是他给我回信中提到的，一并贴出来，供大家参考，希望能共同进步！
89楼
(
) 回复于
2003-04-24 16:52:46 得分
0
好！！
90楼
FLchengang (
飞狼) 回复于
2003-04-24 22:02:07 得分
0
好！！！！！！！！！！！！！！！！！！！！！！！
91楼
wyzegg (
蛋) 回复于
2003-04-25 11:52:07 得分
0
LDAP
92楼
kenpa (
小晨) 回复于
2003-04-25 14:24:44 得分
0
把问题搞复杂化了, 为什么要一个用户可以隶属于多个角色 ???
一个用户只能属于一个权限组!! 这个用户有什么权限,那么新建多一个权限组就行了.
为什么要录属于多个?
93楼
(
) 回复于
2003-04-25 15:54:47 得分
0
没有来得及细看，不过很好，
94楼
pray1997 (
pray1997) 回复于
2003-04-25 16:03:54 得分
0
To： litsnake1(litsnake)
to pray1997(pray1997) ( ) :
怎么样用数字组成字符串来表示啊，
1。你是怎么解决权限的包容关系的
2。你们是怎么解决人员的多角色的问题，例如：一个员工既是财务总监又是经理，就是又多种角色的人，你们是怎么解决权限问题
谢谢！！！！！！
我的意思其实很简单，用一组字符串表示具体的权限，该字符串的组成譬如如下：
全部由数字组成，每两位数字表示一组权限时，则每组最多能包容7种权限(2^8=64)，以及99-63=36个可扩展数字，（每组3位数字时有8种权限，以此类推）。那么所谓的权限包容，比如说权限值为0100表示可读，0200表示可写，操作人员权限值为0600,那么因为1&6=0，所以该人员没有读的权限，但是2&6=2，故该人员有写的权限,如果是0300，则即可读也写
至于所谓的角色，说到底其实还是权限的问题，一个角色其实可以具体表示为一个权限值，多个角色之间的所包含的权限或许有重复，但不同角色本身的权限值是不会相同的，具有多种角色的人员，它的权限其实就是每个角色的权限值相或所得的结果。
不知这么说对不对，请指教
95楼
pray1997 (
pray1997) 回复于
2003-04-25 16:13:00 得分
0
其实用一组数字来表示可能要好得多，但我的工作环境下是没办法的，只能用字符串，所以这只是适合于我的做法而已
96楼
(
) 回复于
2003-04-25 17:41:56 得分
0
权限有这么难吗？也许我没有碰到过最复杂的问题，不过在通常的程序中，我是采用“位”表示相应权限的，一个整型32位，组合起来一共可以表示4个G的权限分类，不过大多数权限是相互制约的，正向前面所说的，修改权就制约着必须拥有浏览权，角色实际上是将一系列预先设置权限组（通常是比较常用的）定义成一个新的描述对象，其划分遵循一定的规则，比如允许一个用户同时处于不同的角色，角色和分离的权限之间有较好的约束关系。这并没有什么难作的。
在界面上，也很简单，权限实际上要严格的和界面元素的状态对应，甚至需要在操作中对权限进行检验，将一些复杂的逻辑关系通过化简，可以转换成若干简单逻辑关系，这些简单逻辑关系可以更好的使用计算机语言来表示，让每一个逻辑单元的状态只和直接相关的状态发生关系，就可以非常容易的设计出很少有Bug的程序。在C++ Builder中可以使用属性来实现，这种设计方法称作以状态为核心的设计方法。比UML中状态机的机制应该更先进一些！
97楼
zealberg (
冰山) 回复于
2003-04-25 18:12:50 得分
0
To： Lewolf(李狼)
“权限有这么难吗？也许我没有碰到过最复杂的问题，不过在通常的程序中，我是采用“位”表示相应权限的，一个整型32位，组合起来一共可以表示4个G的权限分类，不过大多数权限是相互制约的，正向前面所说的，修改权就制约着必须拥有浏览权，角色实际上是将一系列预先设置权限组（通常是比较常用的）定义成一个新的描述对象，其划分遵循一定的规则，比如允许一个用户同时处于不同的角色，角色和分离的权限之间有较好的约束关系。这并没有什么难作的。”
我想你并没有说出解决任何实际问题的办法，“我是采用“位”表示相应权限的，一个整型32位，组合起来一共可以表示4个G的权限分类”，还不如说32位整形数总共有4G个，似乎更能让人明白。对于你们这等高手来说，“这并没有什么难作的。”，而我们刚入门，没办法了，只好就着简单问题翻过来覆过去的讨论。
“在界面上，也很简单，权限实际上要严格的和界面元素的状态对应，甚至需要在操作中对权限进行检验，将一些复杂的逻辑关系通过化简，可以转换成若干简单逻辑关系，这些简单逻辑关系可以更好的使用计算机语言来表示，让每一个逻辑单元的状态只和直接相关的状态发生关系，就可以非常容易的设计出很少有Bug的程序。在C++ Builder中可以使用属性来实现，这种设计方法称作以状态为核心的设计方法。比UML中状态机的机制应该更先进一些！”
我想，权限设计的难点在于设计时需要考虑到实现的复杂程度，也就是应用程序接口实现和界面表示的复杂性，在设计数据库时，必须充分考虑这两点。泛泛而谈“权限实际上要严格的和界面元素的状态对应”可能是高手们的做法，至于将复杂的逻辑关系化简，自然是面向过程设计的基本功，五年前我学C的时候看见过的。
我不知道C++ Builder是怎么实现的，也不明白“状态机”是个什么样的机制，至于怎样非常容易的就能设计出很少有Bug的程序，确实很少人能掌握，太高深！多谢指点！
98楼
(
) 回复于
2003-04-26 14:56:03 得分
0
To:zealberg(冰山)
感谢你的回复，小弟我也主要做MIS系统的。能和大家一起讨论这个问题也算是一件幸事
99楼
zealberg (
冰山) 回复于
2003-04-27 03:54:40 得分
0
做管理软件有些日子了，现在看见代码很头疼，因此偶尔想些主意让自己放松一下，于是把自己的一些想法写下来，尽管很不成熟，若能起到抛砖引玉的作用，则深感荣幸。
这是第100个回贴，非常高兴看到有这么多朋友一起参加讨论，感谢大家对我的思路提出修正意见，特别感谢SW515(孙五)、linlexing(拉拉叉)、clacklin(海风) zoufeiyy(Fly)、eastliangliang(青苹果)等朋友，他们提供的源代码和见解对我有很大的帮助。
如果大家没有其它意见的话，准备结贴了，下一次将贴出修改后的应用程序接口设计思路和伪代码，希望能得到大家的支持！
衷心的祝愿朋友们，身体健康！工作顺利！
zealberg
2003.4.27
100楼
(
) 回复于
2003-04-28 14:16:04 得分
0
sc
101楼
(
) 回复于
2003-04-28 15:18:57 得分
0
对了，突然想起，呼叫转移还有一个功能：无人应答转移，这个就不好弄了，比如规定“A三天内未审批该文档则自动转交到B”，不容易判断“三天”这个日期，自动触发……，高手们想想办法
***********************************
在B或A登录时或试图审批该文档时判断就行了，没必要是真的刚好三天自动触发。
102楼
zealberg (
冰山) 回复于
2003-04-29 01:26:45 得分
0
To： LunnyXiao(风间苍月)
好办法！
103楼
(
) 回复于
2003-04-29 08:34:58 得分
0
各位大佬的高见深感佩服。
不过表示权限还有一种方法，可能效率低一些，不过更直观。
就是用ABCD表示权限
如
查看 A
添加 B
审核 C
删除 D
修改 E
下级部门权限管理 E
则一个人的权限可以用 ACD这样的方法来实现
一共可以有26个权限
要扩展的话，可以用A0-A9这样的方法。
如果要找出有某个权限的用户，可以直接用like '%B%'这样的方法
请大家评论一下
104楼
(
) 回复于
2003-04-30 00:15:04 得分
0
mark
105楼
(
) 回复于
2003-05-22 23:04:48 得分
0
bz
106楼
(
) 回复于
2003-05-24 20:20:18 得分
0
nod!
107楼
(
) 回复于
2003-07-01 15:31:09 得分
0
kao
108楼
maobing (
流浪了一年) 回复于
2003-07-11 14:01:14 得分
0
mark
109楼
st_2000 (
破猫) 回复于
2003-07-11 14:08:55 得分
0
我们做的很简单，只有两个权限表，但所有功能都有了。
110楼
chinawjy (
果冻王) 回复于
2003-07-19 11:07:27 得分
0
再看还是好文，我也要开贴散分。
111楼
dbbdggdbbdgg (
) 回复于
2003-07-20 10:23:38 得分
0
http://www.peoplewarecn.com/xprogrammer/XProgrammer26.pdf
安全模型的一种模式语言
http://www.peoplewarecn.com/xprogrammer/XProgrammer25.pdf
基于角色访问控制的UML表示
供参考
112楼
(
) 回复于
2003-07-30 08:33:28 得分
0
应该有实用的价值。收藏
113楼
Brilliant_DZQ (
一夜未眠) 回复于
2003-08-03 02:02:26 得分
0
前段时间参考HARVEST的思路，写了个权限控制的框架，java写的，也和大家交流下。
分为几个概念：
1.User——用户
2.UserGroup——用户组
3.Permission——权限项
4.Project——项目
5.State——状态，一个项目可有n个状态组成
6.Process——处理项，从属于State，即一个State中可进行多种处理
7.Role——用户角色
权限方面的思路就是将State与Role绑定，将User加入到Role中，通过Role-State
关系判断用户是否有进入State操作Process的权限。
因为设计出发点是一个便于开发的框架，所以开发的过程大致是这样的：
a.分析业务需求，用一个Project进行描述
b.将Project的完成分成几个步骤，每个步骤对应一个State
c.确定每个State有哪些处理要求，构建Process
d.分析用户权限，定义Role，并为每个State确定Role-State关系
e.将User加入Role
也许有网友认为Role的功能与UserGroup重复，而Permission没有使用到。我的考虑
是这样的：
实施HARVEST时，我曾遇到这样一个问题，HARVEST将使用者分为管理员和用户两类，
用户可通过设定角色无穷分类，而管理员确无法细化。为此我认为在角色之上，应该从
系统级上进行一个用户分类，即UserGroup。UserGroup是系统识别的，对用户透明。
Permission的考虑也类似，Permision与User、UserGroup都可建立联系，目的在于让系
统在方法调用时可判断识别，一般我用facade模式构建一个个模块，模块入口类统一控
制Permission。这样的设计是为了使用户在定义权限时简单化，只要定义将不同的User
加入到不同的Role就行，同时也避免系统因为用户权限使用的过于简单，导致系统级权
限管理的弱化。
该框架我主要考虑的是工作流类型的开发，欢迎大家交流，可mail至[email protected]
114楼
newnew (
) 回复于
2003-08-20 09:41:31 得分
0
1、工作流平台是基于java。
2、客户端基于web（采用struts技术），是一个开放的web架构，可以灵活定制，如果扩充功能只需要修改web页面即可
3、工作流平台除满足wfmc标准外，还提供表单设计器，应用表单设计器可以灵活设计各种表单，如果所提供组件不能满足表单需求，也可以写javabean定制自己的组件。
4、所设计的表单以及表单中的字段可以灵活的根据组织机构以及流程设定相关权限。
5、表单设计、流程设计、组织机构设计紧密绑定，构建业务流程以及非业务流程非常方便、快捷。
6、整个系统具有很好的扩充性以及稳定性。
如果客户端没有装java的运行环境,需要登陆后在下载区下载j2re-1_4_1_02-windows-i586-i.exe
然后安装。
http://202.108.204.196/WebAgenda/
ID/Password:F1/F1,F2/F2,F3/F3
如有合作可能联系：[email protected]