Да, этот код позволит сгенерировать auth.php. Мне больше нравится писать его руками.
И про бизрули кто бы объяснил? Не сухим языком руководства, а применительно вот простой задачи. Редактировать свой пост - это бизнесправило? Или операция? Или задача?
Правило — это кусок PHP-кода. Если он даёт true, то роль применяется. Если нет — не применяется.
Редактировать свой пост — это операция. Правило может быть частью операции, роли или задачи.
Попытка запустить yiic rbac ожидаемо ни к чему не привела. Ну и ладно. Надеюсь мне тоже понравится писать руками.. Но как? Sam подскажите же наконец, как будет выглядеть аuth.php c приведёнными выше задачами и операциями?
Последний раз редактировалось Виталий 2009.10.13, 22:48, всего редактировалось 1 раз.
В PostController в методе actionAuth написал этот код. Запустил .../index.php?r=post/auth и ничего. Sam пощадите:) Целый день не могу разобраться.А в первом часу ночи тем более. Я понимаю, что приветствуется самостоятельность и т.д. Но если простой копи-паст вызывает проблемы(см начало топика), то тут, с этим rbacom, я сам не смогу разобраться...
Sam Dark писал(а):Хм… с каких, интересно, пор Yii стал без проверки таскать 'bizRule' по индексу? Обязательно проверю и, если всё-таки стал, поправлю в рецепте.
Поправок в рецепте нет. Это значит что только у меня такой глюк?
class WebUser extends CWebUser{
private $_model = null;
public function init(){
parent::init();
//Yii::import('application.models.user.User');
}
public function getRole(){
return $this->model->role;
}
public function getModel(){
if($this->_model === null){
$this->_model = User::model()->findByPk($this->id);
}
return $this->_model;
}
class PhpAuthManager extends CPhpAuthManager{
public function init(){
parent::init();
Yii::import('application.extensions.my.auth.checkers.*');
// Для гостей у нас и так роль по умолчанию guest.
if(!Yii::app()->user->isGuest){
// Связываем роль, заданную в БД с идентификатором пользователя,
// возвращаемым UserIdentity.getId().
$this->assign(Yii::app()->user->role, Yii::app()->user->id);
}
}
//put your code here
}
Ну и собственно создание ролей, вынес в отдельный action:
class PostChecker {
public static function update($params){
//добавить поддержку сообществ!!!
return Yii::app()->user->Id==$_GET['user'];
}
public static function delete($params){
//добавить поддержку сообществ!!!
return Yii::app()->user->Id==$_GET['user'];
}
public static function create($params){
}
public static function read($params){
}
//put your code here
}
Думаю все понятно. Если будет время, то может напишу свою систему авторегистрации классов выполняющих функцию проверки доступа для определенной группы ролей.
function tasks(){
return array(
'Post'=>'PostChecker'
);
function roles(){
return array(
'user'=>array(
array(self::tasks,'Post')
),
'admin'=>array(
array(self::role,'user')
)
)
}
}
Ну что=то в таком духе. Но сейчас завал на работе, и времени нет думать. Если у тебя есть можем сам заняться этим, а я подключусь как посвободней буду.
Проверил ситуацию с 'bizRule' на 1.0.9. Работает как раньше, т.е. неиспользуемое в роли перечислять необязательно (по крайней мере у меня это именно так).
Пришлось повозиться с ролями, и пришел к следующему выводу, что здесь нет необходимости ни в переопределении AuthManager-а, ни в базовом контроллере, и не надо хранить у пользователя роль. У себя теперь делаю так,
у меня есть пользователи, и группы.
User (id, username, password), Group (id, title, description, type, role - DEFAULT NULL), GroupUser (groupId, userId).
Каждый пользователь может иметь много групп. Причем группы у меня подразделяются на два типа: системные и общие (просто для группирования пользователей).
Изначально сделал консольную команду, где создаю все операции, задачи и роли. Плюс там же создаю системные группы,
где их полю role присваиваю необходимую роль. В интерфейсе сделал, чтобы системные группы редактировать и удалять было невозможно.
Далее, в создании, редактировании пользователя при привязывании пользователя к группе, если поле role !== NULL
выполняю
$auth->assign($group->role, Yii::app()->user->id) и сохраняю - $auth->save(). И наоборот, при удалении пользователя из группы $auth->revoke
Все сохраняется либо в файл, либо в базу данных. В результате теперь нет запутанности с группами, ролями. Все логично, чтобы разрешить что то пользователю, нужно привязать его к необходимой группе.
Ну CPhpAuthManager или CDbAuthManager - в зависимости от задач. А assign ролей с пользователей сохраняется и в файл тоже. Просто когда делал интерфейс редактирования ролей, пришлось перед сохранением вызывать revoke, чтобы связи пользователей не сохранялись, а то иначе когда было прописано assign в PhpAuthManager (или в BaseController) вызывалась ошибка, что роль уже связана с пользователем.