千分求权限设计方面的问题及经验，欢迎大家讨论！！！(300分)

learn

权限表（权限ID、权限说明）角色权限表（角色、权限ID列表）、用户表（用户、角色），可自定义角色，每个角色可灵活配置权限，用户对应角色。

建议看看这篇文章
http://www.jdon.com/jive/article.jsp?forum=46&thread=7309

TO 魔鬼大师：
如果将你说的记录 对应到资源表中的一个资源，对这个资源有查看，修改，删除等操作，
A在创建这条资源时，就拥有了对这资源的所有权限。
而B，C是没有的，除非A 将这个资源的查看授予B，C；B，C是看不到这条记录的。
这只是权限的部分，当然他还牵扯到其他的程序控制

http://www.jdon.com/jive/article.jsp?forum=46&thread=7309
这篇文件的思路和我的大体一致！：）
你可以把要进行权限控制的对象变成一种资源，相同的资源抽象出资源类。
而对资源进行权限管理的是对它的操作，权限控制的是 资源 + 资源操作，

Title ] 关于用户角色权限管理一点想法
[Author] Pizer.Chen
[Email ] Iceant@21cn.com | iceant@vip.163.com
[Date ] 2002-11-3
----------------------------------------------------------------------------
我以前设计过一个权限系统的模型，但是我没有实现，
可以说出来，大家讨论一下。
我认为一个系统的权限部分应该由以下四个部分组成:
[*] Resource
[*] Privilege
[*] Role
[*] User
另外，一个系统中最少有这么几个角色:
[*] Creator， 也可以称做 Programmer.
[*] Administrator, 超级用户
[*] General User
----------------------
权限各部分之间的关系:
----------------------
1. Resource 就是系统的资源，比如部门新闻，文档等各种可以被提供给用户访问的对象.
2. Privilege 是 Resource Related 的权限。
什么意思？就是指，这个权限是绑定在特定的资源实例上的。
比如说部门新闻的发布权限，叫做"部门新闻发布权限".
这就表明，该 Privilege 是一个发布权限，而且是针对部门新闻这种资源的一种发布权限。
我认为，Privilege 是由 Creator 在做开发时就确定的。
3. Role, 是角色，拥有一定数量的权限。
4. User, 与 Role 相关。在我设计的系统里，User是不能与 Privilege 直接相关的，
User 要拥有对某种资源的权限，必须通过Role去关联.
----------------------
系统大串联^_^)
----------------------
下面简单介绍一下，一个权限从开发到使用的过程.
1. Creator 创造 Privilege, Creator 在设计和实现系统时会划分，一个子系统或称为模块，
应该有哪些权限. 拿新闻这一块来说，可能应该有：
[*] 发布权限(publish)
[*] 修改权限(modify)
[*] 审核权限(review)
[*] 浏览权限(visit)
.......
这里完成的是 Privilege 与 Resource 的对象申明，并没有真正将 Privilege 与具体
Resource 实例联系在一起.
2. Administrator 指定 Privilege 与 Resource Instance 的关联.
在这一步， 权限真正与资源实例联系到了一起, 产生了 Privilege Instance。
比如，Administrator 创建了一个叫做 "部门新闻" 的Resource Instance.
?/b>缓蠼?⒉?font style='background-color:#ffff00'>权限与这个资源相关联，产生出 "部门新闻发布权限" 这个 Privilege Instance.
3. Administrator 创建一个角色，称做 "部门新闻发布者".
4. Administrator 将 "部门新闻发布权限" 赋予 "部门新闻发布者".
5. Administrator 从用户列表中选?/b>∫桓龌蚨喔鲇没В?BR> ?/b>缓蟾?庑┯没Ц秤?"部门新闻发布者" 的角色
6. User 进到系统，在它的可访问资源列表上，会出现"部门新闻发布"的链接.
7. User 点击 "部门新闻发布"的链接, 根据 Creator 的实郑?低郴峒觳?BR> [1] 当前用户是否拥有发布权限
[2] 当前用户的发布权限是否与能操作正在访问的资源.
--------------------------------------------------------------------------------------------------
Re 1:
你的方案应该行得通，但是我觉得可以再简化精练一点。
我的思路是这样。
用户角色权限，就设定用户user和角色role的对应关系，user还包括用户组group,　user和group的关系树形结构的关系。
所以，在系统权限这里，我们就可以围绕角色开始定义，抛开user或组的纠缠。如你所说resource 和function(Privilege)组合成一个角色。
提供一个强大的用户权限定制系统，就要在上面两个方面提供定制:
1.可以自行增加　删除　管理resource和function之间关系。
2.可以自行设定用户user和角色role的对应关系。
以你的部门新闻发布为例：
1.某一个新闻为resource . 发布权限(publish) 修改权限(modify)等为function(Privilege)，先设定好这两者关系，比如新闻+发布权限　作为一条记录存入数据库，ID就是roleID,这条记录其实就是一个角色。
2.设定user和roleID角色之间的关系，哪些user包含这个角色role。
通过权限系统框架基本设定，一个用户登陆进来，可以按上面规则检查一下。
我这里与你的区别就是，权限部分应该由以下部分组成：
Role--|-Resource
|_Privilege
User

大家可以讨论一下。
-----------------------------------------------------------------------------
Re 2:
Group 是 User 的集合.
Role 是 Privilege 的集合（应该是Privilege+resource的集合）
-----------------------------------------------------------------------------
Re 3:
对于用户直接拥有权限，我还是不建议让用户直接与权限关联
那如何解决role过多的问题？
-----------------------------------------------------------------------------
Re 4:
role不会过多，与你的设计是一对一的概念。
role可以usergroup对应起来。
role可以说是权限的集合，权限可以有很多，但role只有一个啊。
-----------------------------------------------------------------------------
Re 5:
对于role过多的问题，可以把role按类型进行分组简化管理,如：
DB
|--DBA
|--DBUser
-----------------------------------------------------------------------------
Re 6:
有关权限管理的构成已经基本解决了，接下来是如何使用权限管理？
方案：
1。象iceant 那样
------------------------------------
>>>6. User 进到系统，在它的可访问资源列表上，会出现"部门新闻发布"的链接.
>>>7. User 点击 "部门新闻发布"的链接, 根据 Creator 的实现，系统会检查
>>>[1] 当前用户是否拥有发布权限
>>>[2] 当前用户的发布权限是否与能操作正在访问的资源.
------------------------------------
这里有个问题：资源可能是分级的（树型），可否考虑过？

2。资源列表已固定，在每个资源前加判断，如果有权限则显示该资源，如果无权限则不显示；
3。资源列表已固定，在用户点击链接后加判断
------------------------------------------------------------------------------
Re 7:
你的意思是说，假如 Resource 是 tree type 的.
将 Resource 中的某个节点(非叶子节点)的权限分给用户后，
用户将拥有对该 Resource node 下的所有 child nodes 同样的权限?
这让我想起了操作系统里对文件夹权限的分配.
非常感谢你提出来的这个想法。我是没有想到~!!!
========================================================
理想的状态，当然是 2,3 一起做。
如果是我来做，因为我的视图使用的是面向对象的方式，所以，我可以做一个 View 的基类.在基类里完成 common 的 securityCheck().
其它的视图都 extend 这个 BaseView, 当需要做特殊的权限处理时，可以重写 securityCheck() 方法.
-------------------------------------------------------------------------------
仅仅摘录这一点,原文请参考 下面网址,偶没有研究.
http://www.jdon.com/jive/thread.jsp?forum=46&thread=2897&start=0&msRange=15

：rogue_xu:
我出300分。。。只要你发的东西还可以：） 文档加简单代码
怎么样 。。。。。。。。成交吗》》
applexiaohong@163.com

在父类表单中定义一个Taction的类型变量，加载actionexec的事件，传送消息过去确认帐号和密码，再结合ini文件的初始设置就ok了

什么系统？

权限管理通常没有太大的灵活性，
我给出一个比较通用的模式，
可以进行精细的权限控制，和用户组管理，有点类似于Windows2000的用户管理
表结构如下，
我的对象及关系如下:
用户及用户组对象
用户组是一个特殊的用户,就像Win2000中的一样
系统可操作对象
每个对象是一个可以进行权限控制的最小单位,可以是一个界面或者一个操作,
用户权限分配表
用户和权限对象是多对多的关系,可以用主细表体现,或者树状目录来体现,
每个用户对于每个操作对象又有几种具体权限,包括:浏览,添加,修改,删除,
查询,审批,执行等操作
用户及用户组关系表
用户和用户组为多对多关系,一个用户的实际权限是组权限 或上 用户自身的权限
用户和用户组都可以看作是用户,但是只有用户才能登录

这是我的数据库设计方法和判断权限的方法
/*======================================================================*/
/*用户表 */
/*======================================================================*/
create table s_users(
userid varchar(10) primary key,
username varchar(20) not null,
md5passwd varchar(32) null,
isgroup tinyint default 0,
)
/*======================================================================*/
/*可操作对象表 */
/*======================================================================*/
create table s_forms(
formid varchar(16) primary key,
description varchar(100) null,
menu_path varchar(120) null,
state tinyint default 1,
)
/*======================================================================*/
/*用户及组的关系表 */
/*======================================================================*/
create table s_usermap(
groupid varchar(10) not null,
userid varchar(10) not null,
primary key (groupid, userid)
)
/*======================================================================*/
/*用户及组的权限表 */
/*======================================================================*/
create table s_rights(
userid varchar(10) not null,
formid varchar(16) not null,
canbrowser tinyint default 0,
canadd tinyint default 0,
canedit tinyint default 0,
candel tinyint default 0,
canquery tinyint default 0,
canexecute tinyint default 0,
primary key (userid, formid)
)
/*======================================================================*/
/*获得一个用户所有权限的SQL */
/*======================================================================*/
select
formid,
sum(canbrowser),
sum(canadd), sum(canedit), sum(candel), sum(canquery), sum(canexecute)
from
s_rights
where
userid = '0001'
or
userid in
(select groupid from s_users, s_usermap
where s_usermap.userid = '0001' and isgroup > 0
and s_users.userid = s_usermap.groupid
)
group by
formid
/*这样就获得了所有模块的权限列表,而不用每次都去查询是否有此权限*/
/*如果一个模块某权限的数值大于0表示有权限,否则无权限*/

上面是获得用户 0001 在所有模块上的权限列表,
如果需要判断在某个模块的权限,只需要Locate 然后取权限字段的合计值就可以判断了
如果每次判断权限都去访问数据库,则会引起延迟,
我这样做,就能大大节省判断权限的时间

用户和组实际上是同一类对象，只不过只有用户可以登录，
而组不可以，组的概念和角色的概念比较相似，
便于快速分配权限，同时又可以随意定制一个用户的权限
放在一起可以减少一个表，也便于进行统计和查询

通用授权还是有很多要考虑的，它应该对界面功能（菜单、按纽）和数据（某表、某记录）
都用统一的授权管理方式。
而真正系统应用时，只有在通用授权的基础上进行包装，加入系统独有的权限要求即可

跨地區權限如何設定呢? 在每個一數據表裡都定義區域號?

TO MoQing：
跨地區權限 是什么概念？

有那位富翁的权限设计是用面象对象设计的，请指点指点！！！

我的就是用面向对象的思想来考虑的呀，
操作员对象，
组对象，
可操作对象
以及他们之间的关系

TO LiChaoHui:
不好意思，从你提供的资料还看不出来！
不过我猜想，你程序部分用的面向对象不多。

这个问题，是讨论不完的