在上面,设置的access control过滤器将应用于PostController
里每个动作。过滤器具体的授权规则通过重载控制器的CController::accessRules方法来指定。
class PostController extends CController { ...... public function accessRules() { return array( array('deny', 'actions'=>array('create', 'edit'), 'users'=>array('?'), ), array('allow', 'actions'=>array('delete'), 'roles'=>array('admin'), ), array('deny', 'actions'=>array('delete'), 'users'=>array('*'), ), ); } }
上面设定了三个规则,每个用个数组表示。数组的第一个元素不是'allow'
就是'deny'
,其他的是名-值成对形式设置规则参数的。上面的规则这样理解:create
和edit
动作不能被匿名执行;delete
动作可以被admin
角色的用户执行;delete
动作不能被任何人执行。
访问规则是一个一个按照设定的顺序一个一个来执行判断的。和当前判断模式(例如:用户名、角色、客户端IP、地址)相匹配的第一条规则决定授权的结果。如果这个规则是allow
,则动作可执行;如果是deny
,不能执行;如果没有规则匹配,动作可以执行。
info|提示:为了确保某类动作在没允许情况下不被执行,设置一个匹配所有人的
deny
规则在最后,类似如下:return array( // ... 别的规则... // 以下匹配所有人规则拒绝'delete'动作 array('deny', 'action'=>'delete', ), );因为如果没有设置规则匹配动作,动作缺省会被执行。
访问规则通过如下的上下文参数设置:
actions: 设置哪个动作匹配此规则。
users: 设置哪个用户匹配此规则。此当前用户的name 被用来匹配. 三种设定字符在这里可以用:
*
: 任何用户,包括匿名和验证通过的用户。?
: 匿名用户。@
: 验证通过的用户。
roles: 设定哪个角色匹配此规则。这里用到了将在后面描述的role-based access control技术。In particular, the rule is applied if CWebUser::checkAccess returns true for one of the roles.提示,用户角色应该被设置成
allow
规则,因为角色代表能做某些事情。ips: 设定哪个客户端IP匹配此规则。
verbs: 设定哪种请求类型(例如:
GET
,POST
)匹配此规则。expression: 设定一个PHP表达式。它的值用来表明这条规则是否适用。在表达式,你可以使用一个叫
$user
的变量,它代表的是Yii::app()->user
。这个选项是在1.0.3版本里引入的。
二、查看一下删除请求的方式是否有限制,比如每个控制器的过滤器都是
public function filters()
{
return array(
'accessControl', // perform access control for CRUD operations
'postOnly + delete', // we only allow deletion via POST request
);
}
这样只能通过post方式传递删除请求,而admin视图里的删除时通过get方式传递的,所以我们要将以上代码改为:
public function filters()
{
return array(
'accessControl', // perform access control for CRUD operations
//'postOnly + delete', // we only allow deletion via POST request
);
}