控制
我也请教一个关于权限设计方面的问题
我现在在做一个系统，一个类似信息发布的东东，本来也无所谓，可没想到用户提出了许多BT的要求，尤其是权限方面，本来照我的常规思维，这种东东一般也就是划分几个角色，划分几个信息的发布模块等等也就行了，甚至公司都有现成的东西直接用。
可没想到客户的要求比较刁钻。我先说说系统的大概模样。
信息发布吗，首先当然要划分信息的类别和层次，而这层次是不定的，可能是两三层，也可能是十层、八层（没这么变态吧^_^），其实就类似与windows的资源管理器的样式，目录里面含着文件，而文件又有可能和目录平级的说，这是显示方面大概要显示的东东。现在说说他们在权限控制方面的要求，某个用户登录系统之后，这些目录文件（使用的是资源管理器类似的样式，左边一颗树，右边基本信息列表）将需要根据用户权限的不同而不同（有的目录文件显示，有的不显示的说），当然对于不同的记录用户也需要有不同的增删改权限，列表虽然都能看见，不过有的记录他可以修改却不可以删除，有的却连修改都不许了，当然还有其他的一下操作方式的控制。更为变态的是，要求点击某条记录（或目录、或文件）时弹出的信息查看页面对于不同权限的用户也需不同，即某些字段可以显示，某些字段不能显示（my god，还是把我回收了得了），这就要求在后台的管理方面有着灵活的操作，当然用户也要求了，本着易用性的原则，管理员可以适当选择是对一条条记录赋权还是对一批记录赋权。
说了这么多，不知道各位能否看明白？
我开始的想法是定义组，将某些权限相同的用户赋为一组，然后对记录赋权时根据组进行选择而不用对每个人进行选择，这样就不需对个人进行操作（即使一个人也给他搞个组），这样对组配置改组可以对记录有那些权限，可以显示记录的那些字段，然后针对记录选择组（一个用户可能属于多个组，如有重复，则以用户能获得的最大权限为主）。
不过后来一想，加入某些记录只是针对个人的，如果也这么做的话，会死人的啊，组的数量就太多了。
不过用户的这些要求说到底其实也挺合理，不过实现起来也确实挺头疼，反正我头疼了一个下午了，几张目录文件的表画好后，后台权限方面我死活下不了手了：（
我也希望能够趁这个系统的机会把这个权限管理好好核计核计，反正尽量希望能在设计阶段就考虑完善，最好能将权限这块尽量独立出来，将来在其他系统中可以比较方便地移至（估计也没那个信息系统有这么繁琐的要求了，本来不大的玩意，愣是让他们搞大发了）
但本人在设计方面是个新手，所以感觉难度实在挺大，还是先听听各位在座的高论先，请指教一下该如何下手，信息表与权限表该如何关联，如果有谁做过这方面的东东的话，那就更好了。
所有经验、方法、建议，在下一律欢迎，还请各位不吝赐教，我实在是头都大了
Re: 我也请教一个关于权限设计方面的问题 发表时间: 2003年10月22日 00:36:37 回复
发表人: iceant 发表文章: 413 / 注册时间: 2002-10
1. 对"有的目录文件显示，有的不显示的"疑问
具体到一个目录下的文件是可以控制显示与不显示，但是对目录而言不适合做这样的控制。为什么？假如用户只对 1.1.1 目录有访问权限，那么 1.1 的目录级别要不要体现出来？如果只列用户有权限的目录，那怎么能看得出是 1.1.1 的那个目录？
2.组与用户
你的应用实际上是动态责任确定的应用，在程序规划与实施阶段没有办法获知有哪些角色能操作哪些对象;
另外，权限设计不可过于复杂，否则管理员也会弄不清自己分配的权限是什么样的，最少我自己加个两三层的东东就会头晕。
因此我建议你做基于 ACL 的控制。你提到了想使用组的概念，但是你想为一个人也定义一个组，我认为没有必要，完全可以是用户(User)与 Subject(Folder|Documents)直接对应。如果只能有一个人操作一个目录的文件修改，那你直接授权给某个人，和修改 Role-User Map 关系的维护量没有多大的差别。但是如果对一个目录同一种 Permission 的操作分别授权给不同的用户，维护起来肯定没有建个组或一个角色来得简单。
因此，我的选择是直接使用 Subject,Group,User 的三级关系。
这里先解释几个名词:
Subject: 各种目录，文件等对象
Group: 用户集合
User:用户
Operation: 对 Subject 的某种具体操作，如 Visit,Modify,Delete 等
Permission: 是 Subject 与 Operation 的组合，如：指对某个目录的Visit操作
OK, 那让我们来建几个表吧:
Permissions_Table(
subject varchar(20),--对应目录或文件的ID
user_name varchar(10), -- USER-Subject ACL
group_name varchar(10), -- Group -Subject ACL
operation_type int, --1:visit,2:modify 4:delete,3:visit+modify,5:delete+visit,6:delete+modify,7:visit+modify+delete
subject_type int, --1:dir,2:document
)
user_group_table(
user_name varchar(10),
group_name varchar(10),
primary key(user_name,group_name)
)
再下面....
我相信你有能力做完的....
Re: 我也请教一个关于权限设计方面的问题 发表时间: 2003年10月22日 10:02:00 回复
发表人: ninsky 发表文章: 20 / 注册时间: 2003-10
感谢iceant，你的意见给了我一个思路，某些地方我确实走入了歧途，也盲目的想设计一个通用的东东（估计这就是过度设计）
不过我还想请教一下就是，对于控制到字段的权限模式你能否也提供一点建议呢
我现在就是想多找些人，听一下别人的意见，然后再自己综合一下，希望能够尽量好的实现这套权限管理功能
希望各位多多发言，希望能对我这已经困累欲绝的大脑来点刺激
再次感谢iceant，jdon的讨论风气是我转的几个论坛中最好的一个了
Re: 我也请教一个关于权限设计方面的问题 发表时间: 2003年10月22日 11:16:11 回复
发表人: iceant 发表文章: 413 / 注册时间: 2002-10
"对于控制到字段的权限模式你能否也提供一点建议呢"
什么叫控制到字段的权限模式?
Re: 我也请教一个关于权限设计方面的问题 发表时间: 2003年10月22日 12:19:51 回复
发表人: ninsky 发表文章: 20 / 注册时间: 2003-10
> "对于控制到字段的权限模式你能否也提供一点建议呢"
>
> 什么叫控制到字段的权限模式?
就是对于某个表中的某些字段是可以显示的，而某些是不显示的
当然有个方法是将所有的表的字段及相关的描述信息放到一个数据字典表中，然后对数据字典进行一些相关的赋权操作，不过这样作要求数据字典和所有的表的字段同步
不过总感觉这种方法并不是太好，不过我也没想到其他的方法
Re: 我也请教一个关于权限设计方面的问题 发表时间: 2003年10月22日 12:29:24 回复
发表人: iceant 发表文章: 413 / 注册时间: 2002-10
能不能详细说说你的应用情景? 举个例子
Re: 我也请教一个关于权限设计方面的问题 发表时间: 2003年10月22日 13:41:19 回复
发表人: ninsky 发表文章: 20 / 注册时间: 2003-10
> 能不能详细说说你的应用情景? 举个例子
用户、单位等信息存储在LDAP中，而且是远程的，我的系统虽说取的是LDAP中的用户、单位信息，可是还得提供额外的用户、单位增加功能，也就是说在读取用户、单位信息时要将LDAP中的信息与自己增加的用户、单位信息汇合，重新进行树状排列（这个地方采取生成XML树的方式，不知效果如何），与此同时还要判断当前用户的权限，以便控制各节点是否显示（这些节点可能是单位，也可能是个人）。
然后对各个节点显示的信息还得读取控制权限，那些信息可以显示，那些不能显示，另外对各个信息的操作权限也有控制，对某条信息是增、删、改，还是仅仅查看。而对于某条记录的详细信息，又需控制某个字段是否显示，等等等等，如此这般
我的初步构想：
划分功能点：功能模块（不同用户有不同的操作模块，如我们一般程序顶的菜单项，非LDAP和相关信息）、表结构（数据字典表，控制到字段权限时用）
操作（operate）：增、删、改、查看
角色：赋功能模块，及相关操作
用户：赋角色
组：赋用户
算了，就说这点吧，我也晕了，现在思路很乱
Re: 我也请教一个关于权限设计方面的问题 发表时间: 2003年10月22日 13:54:05 回复
发表人: iceant 发表文章: 413 / 注册时间: 2002-10
我的感觉是你对需求不明确，建义你回去和客户坐下来谈谈他们想要的东东。你可以把操作的界面画出来，然后问问客户是不是想这样操作，如果不是，怎么改动，最后要一个需求更改说明书(可能要你写，客户签字，这也是对你自己的一种保护!)，说明确定下来的需求是什么。