自带的ACF登陆验证 - 扩展角色 ¶

• 作者：KK

• 发表日期：2016.11.02

比如要基于普通用户的时候加个VIP1和VIP2 ¶

控制器有10个业务方法，其中有2个方法要给VIP1以上的用户执行，有1个方法要给VIP2以上的用户执行

1. 先定义一个用户类继承yii\web\User

   并在配置里将user这个组件的class改成这个类，于是用户类就成了你的类，这里初步实现把控制权拿在自己手里了

   ---

2. 重写public function can($permissionName, $params = [], $allowCaching = true)这个方法

   这个其实就是校验权限的方法，既然都重写了这个方法，爱怎么判断就怎么判断啊

   接下来假设用户数据库有个vip字段，0表示普通用户，1是VIP1，2就是VIP2

   示例代码：

   public function can($permissionName, $params = [], $allowCaching = true){
   	if($this->isGuest){
   		return false; //都没登陆当然不通过了
   	}
   		
   	$identity = $this->identity;
   	if($permissionName == 'vip1'){
   		return $identity->vip == 1;
   	}elseif($permissionName == 'vip2'){
   		return $identity->vip == 2;
   	}
   }
   

   ---

3. 配置权限验证的role为vip1或vip2

   配置的书写格式和官方原来教的完全一模一样，就是角色标识符不一样：

   public function behaviors(){
   	return [
   		'access' => [
   			'class' => \yii\filters\AccessControl::className(),
   			'rules' => [
   				[
   					'allow' => true,
   					'roles' => ['vip1'],
   				],
   			],
   		],
   	];
   }
   

   这样在roles里的vip1就会传给can方法进行校验了

对比框架的can方法 ¶

同时你也可以对比一下框架源码的逻辑，主要就多了个_access缓存，就是将校验过的结果存起来，下次再校验这个权限时直接返回

这个在中小项目里一般问题不大，就比如我上面的校验是判断vip字段的值，既然identity都已经findOne出来了那vip字段一般都在了，缓存带来的性价比不大，那我不如不用

大项目可能要用起来，还有RBAC那种要查数据库的，肯定应该缓存而不再去查数据库了，前提也是一次运行周期下来能有2次以上相同权限的查询吧，这个说不准的