权限设计 -- 转载

很多人都知道以角色为基础的权限管理设计（RBAC），但是大部分人似懂非懂，不知道完整的权限管理系统都包括哪些内容。 在此以权限管理的使用场景来说明一下完整的权限管理内容。一是鉴权管理，即权限判断逻辑。 1. 最基本的权限管理就是菜单管理，用户没有权限的功能模块在菜单节点上是不显示的。（很多人以为这就是权限管理！） 示例：普通业务人员登录系统后，是看不到【用户管理】菜单的。 2. 功能权限管理，B/S系统的功能体现为URL，所以功能权限管理主要是针对URL访问的管理。（很多人都不清楚权限管理的对象是什么？） 示例： 经过授权，部门经理可以查看【用户管理】菜单，并查看部门用户信息，但权限设计要求，该部门经理没有添加用户的权限。 所以在访问【添加用户】的功能（URL）时，应该有没有授权的提示信息。 同时在【用户管理】页面上，【添加用户】的按钮应该灰色显示，不能点击。 3. 行级权限管理 示例： 论坛管理员，权限设计要求 A能管理论坛 【新闻版块】，不能管理论坛 【技术交流】 此时的权限设计就应该根据论坛的相应ID来判断权限信息。 4. 列级权限管理 示例： 业务权限设计要求，除销售人员以外，其他用户不能看到客户的联系方式信息。 此时的权限设计要判断相应的字段（列）是否可以显示。 5. 组织机构/部门级数据权限管理 示例: 业务权限设计要求，销售一部的人员只能看到本部门的销售订单，销售二部的人员只能看到本部门的销售订单，但销售经理可以同时看到 销售一部和销售二部的销售订单。 此时的权限设计就要根据销售订单数据本身的部门属性来做判断 6. 范围型业务数据权限管理 示例： 大卖场销售人员在下销售订单时，要选择相应的产品所在仓库信息。 业务权限设计要求，【国美】的销售人员在选择仓库的下拉列表中不能看到【广州仓库】，而【大中电器】的销售人员在选择仓库的下拉列表中不能看到【北京顺义仓库】二是授权管理，即权限分配过程。以上的权限管理内容都要通过系统的授权功能来分配给具体的用户，授权功能应该足够灵活。 1. 直接对用户授权，直接分配到用户的权限具有最优先级别。

　 用户权限字符串==直接绑定每个菜单的ID，再用0表示具备权限，1表示不具备权限；如人员基本信息修改页面的ID为18，张三的权限字符串中有个“181”的子字符串，那么代 表张三不具备查看人员基本信息修改页面的权限。

ps:常在ispostback中判断userid是否为空来表示是否登录，如果用户登入后直接在浏览器中键入url来访问页面，那么就悲剧了，so，要在ispostback中加入权限判断，切记切 记。 2. 对用户所属岗位授权，用户所属岗位信息可以看作是一个分组，和角色的作用一样，但是每个用户只能关联一个岗位信息。 3. 对用户所属角色授权，用户所属角色信息可以看作是一个权限分组，每个用户可以关联多个角色。

如用户(游客，普通登入用户，Vip用户)，管理员（产品管理员，客户管理员），超级管理员。

4. 角色直接关联具体的功能权限（URL），也可以关联负权限，即此角色关联的权限不能使用负权限功能。负权限具有优先级别。 5. 分级授权，系统管理员可以将自己拥有的权限信息授权给其他用户。即可以设置分级管理员和超级管理员。

只有个别人员才具备授予权限功能，且只能授予小于或等于自身的权限。

ps:可以把1、3、5相结合，既可为每个用户单独指定权限，又可避免繁琐的权限勾选操作。

6.权限登记系统。

　 如，把一类页面的权限设为1，另一类页面的权限设为2，那权限为1的用户只能查看权限为1的页面，权限为2的用户可查看1和2的页面。

弊端ps:不适用于论坛等类似系统，原因：采用以上方法，会造成一个论坛的版主能操作权限等级相同或小于自身权限的版块的现象。