php、HTML、网页设计，如何设定权限?

比如你登录后存储用户名是用session， 而且键名是user

那么

在网页2头部加上如下代码：

<?php

 session_start()

 if ( $_SESSION['user'] != 'bc' ) {

  echo '<script>alert("无权限")</script>'

  die 

}

其他的同理！

当然， 具体项目这样做的话， 肯定是不现实的， 那么多用户， 都用用户名来判断的话， 会整死人的！

所以， 我这个代码也只是跟着你的思路走而已！

建议： 数据库再增加一个字段， 用于记录该用户权限

登录成功后， 同时取出该用户的权限字段值，并进行储存（ 比如session ）

然后在每个页面用权限字段来进行判断！

很多人都知道以角色为基础的 权限管理 设计（RBAC），但是大部分人似懂非懂，不知道完整的权限管理系统都包括哪些内容。

   在此以权限管理的使用场景来说明一下完整的权限管理内容。

一是鉴权管理 ，即权限判断逻辑。

   1. 最基本的权限管理就是菜单管理，用户没有权限的功能模块在菜单节点上是不显示的。（很多人以为这就是权限管理！）

      示例：普通业务人员登录系统后，是看不到【用户管理】菜单的。

   2. 功能权限管理，B/S系统的功能体现为URL，所以功能权限管理主要是针对URL访问的管理。（很多人都不清楚权限管理的对象是什么？）

      示例：

      经过授权，部门经理可以查看【用户管理】菜单，并查看部门用户信息，但权限设计要求，该部门经理没有添加用户的权限。

      所以在访问【添加用户】的功能（URL）时，应该有没有授权的提示信息。

      同时在【用户管理】页面上，【添加用户】的按钮应该灰色显示，不能点击。

   3. 行级权限管理

      示例：

      论坛管理员，权限设计要求 A能管理论坛 【新闻版块】，不能管理论坛 【技术交流】

      此时的权限设计就应该根据论坛的相应ID来判断权限信息。

   4. 列级权限管理

      示例：

      业务权限设计要求，除销售人员以外，其他用户不能看到客户的联系方式信息。

      此时的权限设计要判断相应的字段（列）是否可以显示。

   5. 组织机构/部门级数据权限管理

      示例:

      业务权限设计要求，销售一部的人员只能看到本部门的销售订单，销售二部的人员只能看到本部门的销售订单，但销售经理可以同时看到

      销售一部和销售二部的销售订单。

      此时的权限设计就要根据销售订单数据本身的部门属性来做判断

   6. 范围型业务数据权限管理

      示例：

      大卖场销售人员在下销售订单时，要选择相应的产品所在仓库信息。

      业务权限设计要求，【国美】的销售人员在选择仓库的下拉列表中不能看到【广州仓库】，而【大中电器】的销售人员在选择仓库的下拉列表中不能看到【北京顺义仓库】

二是授权管理 ，即权限分配过程。以上的权限管理内容都要通过系统的授权功能来分配给具体的用户，授权功能应该足够灵活。

   1. 直接对用户授权，直接分配到用户的权限具有最优先级别。

   2. 对用户所属岗位授权，用户所属岗位信息可以看作是一个分组，和角色的作用一样，但是每个用户只能关联一个岗位信息。

   3. 对用户所属角色授权，用户所属角色信息可以看作是一个权限分组，每个用户可以关联多个角色。

   4. 角色直接关联具体的功能权限（URL），也可以关联负权限，即此角色关联的权限不能使用负权限功能。负权限具有优先级别。

   5. 分级授权，系统管理员可以将自己拥有的权限信息授权给其他用户。即可以设置分级管理员和超级管理员。

   以上才是一个完整的权限管理系统，你有这样的完整权限的设计吗？

    几乎所有的管理后台都会涉及到权限的设计，权限控制是管理后台的重要功能，可以有效的提高系统的安全性，减少误 *** 作、数据泄漏等风险的发生。但是，很多产品经理会对权限功能有一点害怕的心理，一方面是由于能参考的实例较少，权限管理算是一个“系统级”的基础功能，一般系统中只有管理员可以 *** 作，不像其他功能可以通过去其他系统中试用体验，另一方面，对于权限功能普通用户无法 *** 作使用，所以存在感较低，做好了也不会出彩，可没做好就会导致整个流程不通、产品崩溃。

一 RBAC 模型

    目前，接受度较高的功能权限模型是RBAC（Role-Based Access Control）模型。在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。

1.角色的作用

如果没有角色的概念，直接用户对应权限，虽然会更加灵活，但是后台的数据表设计会变得复杂， *** 作成本也会很高，同时容错能力也会变得很差。

而引入“角色”概念后，用户与角色可为多对一或多对多的关系，当一个用户的角色为多对多时，当前用户的权限是多个角色的并集。此时只需要为角色赋予权限，能够大大减轻管理负担，同时将用户与权限解耦，提供更大的灵活性，同时整个设计的容错能力也提高了很多。

2.引入用户组

   一些大型的平台上，如果用户数量较大，新增角色时，需要为大量用户分配新的角色，工作量巨大，此时可以引入用户组的概念，将这些用户拉到同一个用户组中，然后对整个用户组进行角色的指定，这就大大减少了角色分配的工作量。

同理如果权限较多时也会存在一样的问题，对角色进行权限设置时也需要大量的 *** 作，此时可以考虑引入权限组的概念，将关联性较强的权限大包成组赋予角色，从而减少赋值时的工作量，现实中权限组的使用相对较少，因为系统中的权限一般来讲是有限的。需要注意的是即使有用户组或权限组的存在，也可以允许用户或权限与角色直接关联，这个可以视具体业务情况而定。

下图所示为mac系统中运行添加用户组，并以用户组为单位配置权限。

3. 角色继承的RBAC模型

在一个业务场景中，如果角色需区分：设计主管、设计组长、设计成员，并且管理方式为向下兼容时，则需使用角色继承的RBAC模型。上层角色继承下层角色的全部权限，且可额外赋予权限。

此时除了对角色进行定义，还需要管理角色间的关系，通过关系来体现角色的层级关系，从而达到继承权限的效果。角色的继承关系主要有两种：树形图和有向无环图。

继承关系常常来源于公司团队的组织结构，此时常将角色与组织结构进行关联达到继承角色模型的效果。如下图所示的赵同学，其角色是“三级团队负责人”，与其并列的小组中有多个“三级团队负责人”的角色，但依附于左侧的组织结构树，各级负责人仅有查看和 *** 作自己下属子节点的权限。

4. 限制的RBAC模型

在一个产品或系统中，部分角色可能是需要隔离的、不允许被同时赋予一个人的。跟大家熟知的“不能既是‘运动员’又是‘裁判员’ ”一个道理。

因此，对于众多角色中的一组，只能是单选的关系，但多组角色之间可以共同存在。如下图中，一个用户可以既为设计师又为管理员，但在设计师角色组中仅能被赋予一个角色，在管理员角色组中也仅能被赋予一个角色。

此外，限制还有可能是数量上的，比如一个产品组中必须有且只有一个管理员，不允许删除或再分配管理员角色，仅允许将负责人角色变更。

限制的模型不仅仅对分配过程产生影响，有时即使拥有了多种角色，因为不同的角色对同一个功能的使用方式或数据会产生冲突，所以使用时也需要进行限制。如下图所示为同一时间仅允许以一个身份登录。

根据不同的业务需求，限制的形式很多。需要注意的是不能仅依赖后端限制，而是要在前端展示清晰的规则和恰当的限制，避免用户出错和沮丧。

三、权限的拆分与设计

通过RBAC模型已经能够很好的搭建起用户、角色与权限之间的关系了。但具体是什么样的关系，以及“权限”这个抽象的概念具体如何规划？

这些都需要分析清楚才能进一步设计出完善的权限系统。

首先需要知道，一般产品的权限由页面、 *** 作和数据构成。页面与 *** 作相互关联，必须拥有页面权限，才能分配该页面下对应的 *** 作权限。数据可被增删改查。

整体关系如下图所示：

因此，在设计之初我们就需要考虑到未来可能区分角色的地方，尽量解耦、模块化。对于技术来说，每一个页面模块、每一个 *** 作都最好使用独立的接口。对于设计来说，需要保障所有角色因为权限而屏蔽掉部分 *** 作和数据后，页面和流程仍能体验流畅。

保证初期设计支持后，配置权限时，还需要注意以下几点：

（1）确定是否支持前端配置

如果角色和权限相对固定，则一般将角色与权限的关系可以写在后台，改动时需要后端变更且重新上线。这种情况适用于公司内部系统等只有一个使用主体的系统。

如果需要自定义角色或者每个角色在不同使用者的场景下有不同的权限，则需要将角色的定义、角色与权限之间的配置体现在“前端用户配置页面”。这种情况适用于有频繁变动的自定义角色权限，和有租户体系的系统。

（2）以基本单元拆分，以业务逻辑配置

一般可将每个对象的“增、删、改、查”各自作为一个基本的权限单元。打个比方，在“人员管理”中，查看人员列表、添加人员、删除人员、编辑人员信息最好拆分为4个权限单元。在技术和设计上，我们希望能尽量做到解耦和模块化。

但是在业务层面有些 *** 作却是一体的。这些不能拆开的权限在“前端用户配置页面”中建议打包成一个整体提供配置。例如：如果我们确定在系统的现有和未来业务中，仅分为普通成员有“人员管理”的查看权限，管理员有 *** 作权限，则可将“增、删、改”三个基本权限单位合并为“ *** 作”权限进行配置。

（3）页面权限优先于 *** 作和数据权限

必须配置了页面模块权限后，才能配置当前页面模块下具体的 *** 作权限，以及页面模块的数据展示权限。

（4）查看权限优先于增删改权限

正常情况下，一定要先能查看某个模块或 *** 作，其它的增删改 *** 作才有意义。因此在设计时，应在获取查看权限前限制其它权限的配置，或者配置其它权限时默认赋予查看权限。

（5）角色与权限的多种关系

角色与权限的关系不仅是单纯“是/否关系”，还包括以某种限制进行 *** 作，和以某种程度访问数据。

例如在“人员管理”中：

数据范围：用户拥有查看人员列表的权限，但仅能查看自己所在的团队；数据边界限制（上限等）：添加人员时不能超过20个等。数据字段：HR能查看人员列表中包括职级、薪资等字段，其它角色仅能查看姓名邮箱等字段；

（6）角色与权限的设计表达

在传达一个系统的权限设计规则时，设计师常常习惯用主观最直接的方式表达想法，如用“当……时，就……”的句式来表达。但一个平台中涉及的权限规则是非常多的，当通篇以这样的形式描述时，表达对象将很难理解。

正确的描述方式：更清晰的是基于开发的语言，和技术模型的结果进行表达。将各角色与权限单元绘制成网格，每个交叉点网格中描述该角色与权限的数据关系和限制。

如下图所示：

四、需要注意的Tips

1. 隐形的admin

在可自定义角色和权限的系统中，一般需要预留一个admin角色来进行系统的初始配置，用于添加首批的业务人员和配置基本的角色。

有的系统中允许存在上帝视角的admin角色，则其可以作为“超级管理员”显示在角色配置的列表中。有的系统中不允许这种角色存在，则可将这种角色设置为隐形的状态，仅赋予维护系统的工作人员。

2. 初始权限的赋予

对于允许用户自行加入的系统，需要设定一至多个默认的角色，有时可以是仅有最基础权限的“游客”角色。

初始权限还可以与用户既有的某些数据字段进行关联，如添加用户时获取到用户的岗位为“设计师”，则直接赋予“设计师”角色的权限。

3. 人员管理中对自己的处理

在人员管理中，管理员角色处理自己时需要额外注意。因为如果修改或删除了自己角色后，可能导致系统没有管理角色，从而无法添加其他成员和正常运行。设计时可添加判断，当自己为唯一管理角色时，禁止编辑和删除。

4. 无页面权限的提示

虽然可以通过页面权限限制直接隐藏当前用户没有权限的页面，但不能排除用户获取到权限外的url地址。当用户意外访问到没有权限的页面时务必提供“无权限”的提示，避免用户认为系统bug。

最后

总结一下，整个权限系统设计就是定义各个节点和节点间关系的过程。

节点包括：

用户；用户组；角色；角色组；权限（页面、 *** 作、数据）；权限组（页面、 *** 作、数据）；

关系包括：

是/否关系；继承关系；限制关系（互斥、范围限制、边界限制、字段限制……）

---