Forums项目的权限设计思路分析
Forums项目的权限设计思路分析
作者：Richard-Wang
下述文章内容，关于权限设计模式研讨部分，参考了网络上的一些帖子的内容，文中已做特别标记。其他均为原创文字。
l 权限管理元素分析
n 任何一个系统，与权限管理相关的元素包括：
u 信息对象
l 对象类型
l 对象范围
u 操作权限
l 操作内容：{浏览，阅读对象内文章，发表帖子，……}
l 权限值：{允许，拒绝，未设置}
u 用户
l 用户类型：{单个用户，用户群}
l 用户标识：唯一地指定用户对象{如：用户ID，科室ID，地区ID，……}
n 角色是用来标识“特定信息对象的一组操作权限”的特殊权限对象。
u [角色ID]+[信息对象：[信息类型]+[信息范围]]+[操作1，权限值]……+ [操作n，权限值]
u 上述记录完整地记录了一个角色对指定对象应该的所有操作权限，是1维权限的组合。
u 在任何情况下，[角色ID]+[信息对象：[信息类型]+[信息范围]]的值是唯一的，不能重复。
u [[角色ID]，[信息对象]]是权限管理最有效的最小元素
n [操作i，权限值]：{i=1，……n}代表单个操作权限，是权限管理的最小元素。
l 权限设计思考
n 在权限设计中，引入[角色]这种特殊元素，是基于权限管理的效率和管理逻辑清晰化的需求，而认为生成的。它与人类社会中的官职是对应的，也是人类社会的形而上的意识层面copy到计算机软件环境的一种体现。
n 许多系统，在设置一个角色时，没有指定信息对象范围，这是一种错误的设计理念。因为，这意味着该角色应用于系统的所有对象，如：某人被委任为科长，并不意味着他能够在任意科室都行使科长的权限。
n {[角色]+[板块ID]+[各种操作权限]}的权限管理模型是比较高效的，但为某一个用户委任一个职务，却不能使用直接赋予[角色]的方式指定，而应该使用<[角色]，[信息对象]>的方式来指定。
u 假如直接赋予[角色]的方式指定，就会使该用户获得了一组权限{<[角色]，[信息对象1]>，......，<[角色]，[信息对象n]>}
u 因此，用户权限信息表应该由2个表来组成。
l 其中一张表，仅仅包含<[用户ID]，[角色ID]>的记录，此为普通权限信息表。
l 而另一张表，则包含<[用户ID]，[角色ID]，[信息对象ID]>的记录，此为特殊委任权限信息表。
l 前者定义用户的普通权限，而后者定义用户的官职权限，如：某论坛版主，或系统中的科长，ETC。
n 权限的管理信息，不仅仅存在于权限信息表，还存在于信息对象中，如：某BBS板块是否允许发表主题的作者执行删除主题的操作？。。。。。。
n 权限的作用，一般体现在以下方面：
u 打开某个网页
u 在某个页面上执行操作
u 在某个页面上根据用户权限筛选显示内容
n 特殊的权限作用模式
u 有时候，权限是动态计算的结果。如：某用户积分不够，不能下载某个文档/打开某个页面。这种处理往往需要在用户的动作响应方法代码中发出警告。
u 有时候，在页面显示数据时设置隐藏/部分隐藏，如：用户对当前主题没有回复过，用户的积分不够/角色权限不足，不能显示全部内容。这些处理也要在执行代码中，酌情处理。多数在数据获取期，和数据绑定期，采取一些相映的处理。
u 有时候，系统会根据用户特殊角色，来决定是否允许其执行某操作，如：系统管理员的各种操作。
n 当用户的操作超出了权限范围，系统就会发出警告。使用自定义异常来发出警告，然后程序进入错误中断处理，由错误信息页告知用户出现了哪些错误，这是一种主动、有效、友好的信息。
n Forums框架下的权限设计还是非常优秀的，基本上是标准权限管理模式。
u 但该模式是针对板块对象设计的。
u 在帖子对象中还有一些权限控制信息，如：主题是否已经被锁定，不能再增改。ETC……
l 这些针对帖子的权限信息被放到帖子的信息单元中。
u 板块对象与帖子对象都可以进行个性化权限控制，而控制信息都放在其对象信息单元体中。
u 如果一个系统中包含比较多的数据种类，
l 比如：物资供应系统
n 物资分类与人员之间的操作权限
n 打印单据权限
n 各种审批操作权限
l 这些权限在物资供应系统中都是相对独立的，相互之间的最大区别就在于信息对象的类型不同。
l 因此，必需针对不同信息对象的类型创建相应的{[角色]+[板块ID]+[各种操作权限]} 权限信息记录表。
l 也因此，如果系统中有n个复杂对象需要权限管理，就存在n个与forums_ForumPermissions表类似的权限信息表。
l 但forums_Roles和forums_UsersInRoles表却可以始终保持一个。
l 权限设计模式研讨
n 基于角色的权限设计模式{他文引摘}
u 这种方案是最常见也是比较简单的方案，不过通常有这种设计已经够了，所以微软就设计出这种方案的通用做法，这种方案对于每一个操作不做控制，只是在程序中根据角色对是否具有操作的权限进行控制；这里我们就不做详述
u 基于角色的权限设计模式适用于简单权限管理模式，好处在于可以在配置文件中配置页面的权限，而且不用编写代码，直接调用微软的代码库。
u
n 基于用户的权限设计模式：
u 这种方案为特定功能或页面群提供一个数据库用户名单表，存储被允许的用户ID。
u 每一种功能功能都必须创建一个数据库用户名单表。
u 这种做法对于特殊功能特殊人群权限管理的系统而言是可行的，除此之外，这种做法会带来大量的数据库表。而且影响业务逻辑的灵活处理。
n 基于操作的权限设计模式：{他文引摘}
u 这种模式下每一个操作都在数据库中有记录，用户是否拥有该操作的权限也在数据库中有记录，结构如下：
u 
u 但是如果直接使用上面的设计，会导致数据库中的UserAction这张表数据量非常大。而且中间业务层对Action表的处理将会十分复杂。
n 动态权限条件计算的权限设计模式：
u 通过动态计算用户信息，计算出用户的操作权限。
u 适用于积分型站点系统的权限管理
u 往往通过站内积分来区分用户操作VIP级别
u 在一个主题中，回帖的用户给与隐藏内容的解密，也是这种权限管理模式。
n 动态角色的权限设计模式：
u 这是对动态条件模式的一种变通。由于每次计算用户操作权限必定耗费服务器CPU和网络资源，所以，采用积分改变，触发角色变更。
u 积分改变多数是用户的某个操作之后发生，如：发一个帖子。此时，用户的积分会发生变化，根据这些变化的结果，重新估算是否要修改/增加用户的角色。
u 由于下一个操作还没有发生，用户的前一个行为造成的用户角色的变化就可以影响下一个操作的权限。
u 这种模式常常与角色管理模式一起使用。
n 论坛模式：
u 由[信息范围编码]确定使用权限信息对象
u 由[操作权限1，…….，操作权限n]确定一组操作的[允许/不允许/未确定]状态
u [角色编码]+ [信息范围编码]来确定最小权限管理信息单元。如：Forums系统中的forums_ForumPermissions表。
l 由于用[角色编码]作为权限管理信息单元的属性，所以，没有相应角色的用户就会被拒绝
u 用户权限信息表应该由2个表来组成。
l 其中一张表，仅仅包含<[用户ID]，[角色ID]>的记录，此为普通权限信息表。如：Forums系统中的forums_UsersInRoles表。
l 而另一张表，则包含<[用户ID]，[角色ID]，[信息对象ID]>的记录，此为特殊委任权限信息表。这张表在Forums系统中没有出现，不能不说是一种缺陷。
l 前者定义用户的普通权限，而后者定义论坛的管理者权限。如：某论坛版主，ETC。
u 必须注意的是：所有[信息编码]对应得信息对象的类型和格式必须相同，才能行使该类型的权限管理。
l 比如：不能将网站管理的页面权限与论坛板块操作的页面权限混在一起，放在同一张SQL表中。
l 虽然可能在模式上相同，毕竟操作上是不同的。混在一起，就可能出现一些操作权限字段对于某些信息对象没有意义。
l 而且，从权限管理逻辑上而言，这是一种混乱。
l 其实，可以建立2张SQL表来存放不同类型的信息对象的权限管理信息。
n 一个站点的权限管理往往混杂了多种管理模式，如：某一个主题的显示页，可能同时使用了论坛模式和动态条件模式。而实现这些模式的代码，多数都在中间业务处理类中实现。
l Forums项目权限管理模式分析
n 在Forums项目中，与权限相关SQL表包括：
|
数据表名称 |
注释 |
|
forums_Roles |
论坛角色信息表 |
|
forums_UsersInRoles |
用户所能充当的角色信息表 |
|
forums_ForumPermissions |
论坛角色权限信息表 （[板块]，[角色]）对应的操作权限 |
n 角色管理
|
|
数据表名称
n 板块权限管理：为每个板块分配权限，并为指定板块的指定角色分配操作权限
此操作由管理员负责，结果存入forums_ForumPermissions论坛角色权限信息表。
注意：
u 不同的角色在不同的板块中可以执行的功能可以不同。
u 一个板块可能是某个父板块的子板块，但从数据库中，该板块是独立的，与其父板块拥有相同类型的板块信息，信息放在同一张表格中，拥有不同的ID。
u 某个板块中的子板块，可以分配以与父板块完全不同的权限。
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
n 用户角色分配：在用户管理中进行。也可以设定条件触发式角色分配，或定时触发条件角色分配。
注意：
u 一个用户可能拥有多个角色，而每个角色对应于某个板块而言，其各种操作权限是指定的。如此，就可能出现一个用户在某个板块的指定操作因为不用的角色而有不同的操作权限。但其实，该权限是唯一的。因为用户的权限是可以合并的，取最高权限[允许]来作为用户指定操作权限，或明确权限[不允许]来覆盖其他[未设定]权限。
|
数据表名称： forums_UsersInRoles 中文名称：用户所能充当的角色信息表
|
n 所有的板块信息都至少包括以下2个字段：父亲板块ID、讨论组ID。
一个板块可以没有父亲，但必定归属于某个讨论组。
|
n 权限执行的位置：
u 获取讨论组时，剔出用户不能访问讨论组，如：Default.Aspx、/Moderate/home.aspx、/Admin/ManageForums.aspx等
u 获取板块列表时，剔出用户不能访问板块
u 操作帖子列表时，对用户不能访问的板块的帖子列表抛出异常对象
u 操作帖子时，对用户不能访问的板块的帖子抛出异常对象
u ETC
n 设计权限的方法：
|
AspNetForums.ForumGroups.GetForumGroups(…) |
获取讨论组列表 |
|
AspNetForums.ForumGroups.GetForumGroup(…) |
获得指定论坛组ID的论坛组对象 |
|
AspNetForums.ForumGroups.GetForumGroupByForumID(…) |
获得指定板块ID的论坛组对象 |
|
AspNetForums.Forums.GetForums(…) |
获得指定板块ID的Forum列表对象 |
|
AspNetForums.Forums.GetForumsByForumGroupID(…) |
获得指定论坛组ID的Forum列表对象 |
|
AspNetForums.Forums.GetForum(…) |
获得指定板块ID的Forum对象 |
|
AspNetForums.Forums.GetForumByPostID(…) |
获得指定帖子ID的Forum对象 |
|
AspNetForums.Posts.[Method Name](…) |
获取各种条件下的PostSet |
|
AspNetForums.Posts.[Method Name](…) |
获取各种条件下的Post |
|
……………………..ETC. |
|
n Forums权限管理设计模式的改进
u 仍然保留以下2表
|
数据表名称 |
注释 |
|
forums_Roles |
论坛角色信息表 |
|
forums_UsersInRoles |
用户所能充当的角色信息表 |
|
forums_ForumPermissions |
论坛角色权限信息表 （[板块]，[角色]）对应的操作权限 |
n 同时，增加1表
|
数据表名称：UserPermissionsInForum 中文名称：特殊权限信息表
本表是对UsersInRoles表所指定的用户权限集合的补充。 |
u 上述修改评价：
l 通过上述修改，我们可以指定个别用户作为指定板块的版主，而不是直接为其分配版主角色。
l 如此，指定板块的版主就只能在指定板块行使版主管理权限。如此，板块管理权限就与现实世界完全吻合了。
l 如果，指定板块的版主还能够指定下属子板块的版主，那么，子板块的版主的权限范围只能限制在某子板块中。
l 如果，指定板块的版主还能够指定副版主协助管理，那么，副版主的权限范围只能限制在当前板块中。
l 另外，父板块的版主角色不可以延伸到下属板块中。当然，如果我们希望可以延伸的话，最好给该版主提供一个可以创建子板块版主的权限角色，这样，该版主就可以自己将自己添加到子板块的版主角色中。如果我们希望严格管理，那最好不要给下属版主如此大的人事权限，这与人类社会的惯例相同。
l 经过上述修改后，Forums项目的权限管理设计，既有刚性的有效，又有柔性的变通，显得非常完美。
l 比较全面的权限设计模式
| |||||||||||||||||||||||||||||||||||||
比如： 信息对象为：板块 typeID:forum 信息对象为：物资分类对象 typeID:forum typeID字段是用来方便搜索和记忆的，表主键才代表信息类型并应用于其它表对信息类型的标识。 | |||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||
本表对应于信息类型表的[ID]=1，typeID= [Forums]，一般用信息存储SQL表的名称作为[信息类型编码]。 | |||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||
|
数据表名称： UsersInRoles 中文名称：用户所能充当的角色
数据表名称： RolePermissions 中文名称：角色权限表
上述2表，可以界定用户权限集合的主体。 | |||||||||||||||||||||||||||||||||||||
|
数据表名称：UserPermissions 中文名称：用户权限信息表
本表是对UsersInRoles表所指定的用户权限集合的补充，相同PermissionsID值的操作权限值Value以本表为准，而不是合并权限操作 | |||||||||||||||||||||||||||||||||||||
|
数据表名称： UsersInInformations 中文名称：用户所能操作的信息范围
本表信息用来辅助管理员进一步缩小用户权限有效范围。 也可以用UserID=0来确定新用户的初始权限作用范围，辅助管理员创建用户权限集合。 |
n 上述设计的评价
u 缺点：
l 对同一个角色对同一个对象因为不同的操作生成了多个记录，其实可以合并为一条记录，通过记录中字段来区分哪一个操作的权限值是什么。但这样就不能随便改权限管理模式。这与Forums项目的权限管理信息表基本相同。
l 对于生成指定板块的指定用户的权限集合来说，需要执行更多的判断。这就降低了代码的效率。
u 优点：几乎适应所有管理需求，尤其是在做ERP之类的大项目时，尤其适用。同时，如果用户需要增加/减少操作类型，上诉权限管理设计模型几乎不用做任何SQL表结构的改动。因为，如果改SQL表结构，几乎就等于重新设计一次系统，那样工作量往往大得惊人。
u 意见：
l 如果系统规模比较小，最好引入Forums项目的forums_ForumPermissions表，这样，通过这个稍为刚性的[范围]+[角色]+[权限1—n的值]，加快SQL到程序内存对象的权限信息传递速度，以牺牲部分灵活性来提供权限信息访问的效率。上面对Forums项目的权限管理设计模式的修改，基本上反映了这种要求。
l 上诉设计模式还缺少用户的类型，如果需要将权限分配给某一个单位对象，上述模型需要稍微修改一下。
2010年07月31日
