权限控制
说到权限控制，有人不明白为什么要单独设计权限模块，难道不能直接在代码里面直接写死一些权限的控制吗？
是的，确实可以，但是如果你需要更换权限的时候不改动代码的话，那你就需要好好设计一下权限这个模块。
权限控制的三要素：用户-用户组-节点，正是这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。
关于权限控制，如果大家有好的操作方式，一起探讨。
