自带的ACF登陆验证 - 活用can方法 ¶

• 作者：KK

• 发表日期：2016.11.02

一般来说User类的can方法是在控制器自动运行过滤器时自动调用的，不需要我们手动调用，要扩展什么的重写can方法的逻辑就行了

但其实可以这么玩，首先要扩展角色就重写can的逻辑做自己的校验，默认就是提供给过滤器自动调用做校验的

然后有一些权限控制比较复杂的方法就只做@角色的登陆权限校验，而在执行时再进一步通过can方法判断用户的其它权限

下面是一个示例控制器：

class XxController extends \yii\web\Controller{
	public function behaviors(){
		return [
			'access' => [
				'class' => \yii\filters\AccessControl::className(),
				'rules' => [
					[
						'allow' => true,
						'actions' => ['add-member'], //就这个方法只要@角色就可以
						'roles' => ['@'],
					],
					[
						'allow' => true,
						'roles' => ['vip1'], //其它方法全部都要vip1
					],
				],
			],
		];
	}
	
	public function actionAddMember(){
		$xxx = yyy();
		if(Yii::$app->user->can('vip1')){
			qqq($xxx);
		}else if(Yii::$app->user->can('vip2')){
			vvvv();
			/*我的项目试过这样，增加了一个 test-user 的权限角色
			其实这个就是我们员工的测试账号，做一些特殊处理，当然其实项目中应该尽量避免这样，但中途参加的项目有历史遗留问题又奈何呢……*/
			if(Yii::$app->user->can('test-user')){ 
				jjjj();
			}
		}else if(Yii::$app->user->can('vip3')){
			//干嘛干嘛的
		}
		
		//更多。。。其实真实场景比这种逻辑还复杂
	}
}

其实上面的actionAddMember就是通过can对权限校验的返回来决定要不要运行哪一块代码，这是最细的权限控制级别了，完全可以控制到每一条语句要不要执行

而从前的确有不少人受限于RBAC只能控制到控制器方法而苦恼，至少我觉得无须动不动就用RBAC吧？