php多种权限,php系列（五）权限控制的思考

权限控制

说到权限控制，有人不明白为什么要单独设计权限模块，难道不能直接在代码里面直接写死一些权限的控制吗？

是的，确实可以，但是如果你需要更换权限的时候不改动代码的话，那你就需要好好设计一下权限这个模块。

权限控制的三要素：用户-用户组-节点，正是这3者之间扯不清的关系，形成了权限控制的复杂性。(注：节点：用户的任何的一个操作都被称为节点)

RBAC权限控制

很多人在做权限控制的时候习惯性的去使用RBAC这种方式：用户对应用户组，用户组对应节点，用户组拥有的权限即这个用户所有的权限。

这种方式有个比较明显的缺点：

颗粒太粗：权限控制只能到分组，当管理员组下面有100个用户，这100个用户需要根据每个用户的积分值情况再分配不同的权限，那这个就很难实现。

RBAC的这种缺陷，我们的auth权限控制可以弥补!

AUTH权限控制的优势

粒度很细：能在分组下再根据用户的一些属性进行权限的分配。

先来看看RBAC的表设计

用户表:

用户名称 积分

小明 188

小红 233

小花 92

用户组表:

用户组名称

一级管理员组

二级管理员组

三级管理员组

超级管理员组

节点表:

节点说明 节点名称

抽奖 activity/chou

抢红包 activity/qiang

砸金蛋 activity/za

用户组与节点关系表:

用户组 权限

管理员组 抽奖，抢红包，砸金蛋

用户与用户组关系表:

用户 用户组

小明 管理员组

RBAC的权限判断也很简单：

(1)根据用户得到用户组

(2)根据用户组得到节点

(3)判断需要验证的节点是否在用户所拥有的节点列表中，在就有权限，不在就没有权限

再来看看AUTH的表设计

用户表:

用户名称 积分

小明 188

小红 233

小花 92

用户组表:

用户组名称

一级管理员组

二级管理员组

三级管理员组

超级管理员组

节点表:

节点说明 节点名称 附加规则

抽奖 activity/chou {score}>1 &&{score}<100

抢红包 activity/qiang {score}>100 &&{score}<200

砸金蛋 activity/za {score}>200 &&{score}<300

用户组与节点关系表:

用户组 权限

管理员组 抽奖，抢红包，砸金蛋

用户与用户组关系表:

用户 用户组

小明 管理员组

光看上面的表设计，其实我们可出看出两者的区别：

在节点表的设计中，auth比rbac多了一个附加规则的字段。

多了一个字段也就多了一个判断，AUTH权限判断步骤如下：

(1)根据用户得到用户组

(2)根据用户组得到节点

(3)判断需要验证的节点是否在用户所拥有的节点列表中，在的话进行步骤4的判断，不在的话直接提示没有权限

(4)如果有附件条件，再判断下用户的属性是否符合附加条件，符合才返回符合权限，否则返回没有权限。

关于condition条件的判断代码实现的逻辑

前面我们看到节点表里面，多加了一个condition字段，这个字段的写法是{score}>100 &&{score}<200,我们在权限判断的时候，先用正则替换的方式将这句话变成$user['score']>100&&$user['score']<200，然后用eval函数执行这段话，然后记录这个语句的返回值true/false来作为判断是否有权限的依据。

AUTH权限控制存在的不足

由于AUTH权限的节点表设计的时候多加了一个condition字段，对节点进行验证的时候，比如有一个节点是审核操作，condition是score>100，如果需求是用户是初级管理员组必须score>100才能进行审核操作，而高级管理员组却可以直接进行审核操作，那么对于这种权限控制，auth也无法控制，因为多个组共享了一个节点的condition。

关于权限控制，如果大家有好的操作方式，一起探讨。