Я думаю, все, кто хоть немного работал с фреймворком Yii знают, что он поддерживает возможность разграничения прав доступа на основе ролей.

Принцип работы этой системы достаточно прост. Вы создаёте наборы правил и пользователей, связываете их между собой. После этого, вы в любой момент можете проверить, имеет ли пользователь право на выполнение какой-то операции или нет.

Одно из основных преимуществ использования данной библиотеки заключается в том, что вам нужно написать минимум кода для проверки прав доступа. Обычно этот код выглядит следующим образом.

if (!Yii::app()->user->checkAccess('createUser')) {
	throw new CHttpException(403, 'Forbidden');
}
//остальной код…

В теории всё просто. Но на практике, документации и примеров по этой теме практически нет (надеюсь, это скоро изменится).

Основные источники информации (на русском): Аутентификация и авторизация и RBAC и описание ролей в файле. На английском хороших и подробных примеров, к сожалению, я не нашел.

Примечание. Очень советую прочитать эти статьи, прежде чем переходить к моему примеру.

Когда я первый раз решил использовать RBAC, то выяснилось, что есть множество нюансов, которые приходится учитывать при работе с этой библиотекой. Ничего запредельно сложного и недоступного для понимания, но «ковырялся» я довольно долго

В этой статье мы рассмотрим пример создания несложной системы управления пользователями (идея взята из одного web приложения).

Постановка задачи.

Есть три типа пользователей.

Обычный (user) – может создавать и редактировать свои данные (например, список контактов) и изменять свои логин/пароль.

Администратор (admin) – может создавать новых пользователей, но не может изменять их данные. Он может изменить свои собственные логин и пароль, но не может изменить роль.

Суперпользователь (root) – может выполнять любые операции с пользователями.

Ни admin, ни root не имеют доступа к персональным данным пользователя (которые он создаёт при работе с приложением).

Примечание. Чтобы сократить объем кода, я урезал набор правил. Но, думаю, вы без особого труда сможете его дополнить. Главное понять идею и принцип работы.

Шаг первый. Выбираем тип хранилища для ролей и операций.

Для этих целей Yii позволяет использовать PHP файл (CPhpAuthManager) или базу данных (CDbAuthManager).

Если вы предполагаете, что количество пользователей будет большим, то лучше использовать БД. Но для знакомства с библиотекой лучше использовать PHP файл, т.к. читать его легче. К тому же перейти от одного типа хранилища к другому совсем несложно.

Для того, чтобы Yii «узнал» о вашем выборе, в массив с настройками (config/main.php) нужно добавить следующий элемент.

'components'=>array(
…
	'authManager'=>array(
		'class' => 'CPhpAuthManager',
	),
),

Шаг второй. Создадим таблицу в БД для хранения пользователей.

Эта таблица будет состоять из шести полей.

u_id – первичный ключ;
u_name – имя пользователя;
u_email – адрес почты (используется как логин);
u_pass – пароль;
u_state – статус (активен, заблокирован);
u_role – роль пользователя (root, admin, user).

В данном примере для нас играет роль последнее поле (u_role).

Шаг третий. Создаём операции, роли и задачи.

Я очень надеюсь, что вы прочли статью из Полного руководства и знаете, что представляют собой операции, роли и задачи и зачем они нужны.

Сразу перейдём к созданию файла с этими настройками.

Т.к. в качестве хранилища мы выбрали PHP файл, то можно создать его вручную (этот способ подробно рассмотрен в статье RBAC и описание ролей в файле).

Но, на мой взгляд, гораздо удобнее использовать API. Поэтому создадим небольшой инсталляционный скрипт (контроллер SiteController метод actionInstall).

Примечание. Данные будут сохранены в файле protected/data/auth.php. Файл будет создан автоматически, поэтому запись в эту папку должна быть разрешена.

public function actionInstall() {

	$auth=Yii::app()->authManager;

	//сбрасываем все существующие правила
	$auth->clearAll();

	//Операции управления пользователями.
	$auth->createOperation('createUser', 'создание пользователя');
	$auth->createOperation('viewUsers', 'просмотр списка пользователей');
	$auth->createOperation('readUser', 'просмотр данных пользователя');
	$auth->createOperation('updateUser', 'изменение данных пользователя');
	$auth->createOperation('deleteUser', 'удаление пользователя');
	$auth->createOperation('changeRole', 'изменение роли пользователя');

	$bizRule='return Yii::app()->user->id==$params["user"]->u_id;';
	$task = $auth->createTask('updateOwnData', 'изменение своих данных', $bizRule);
	$task->addChild('updateUser');

	//создаем роль для пользователя admin и указываем, какие операции он может выполнять
	$role = $auth->createRole('admin');
	$role->addChild('createUser');
	$role->addChild('viewUsers');
	$role->addChild('readUser');
	$role->addChild('updateOwnData');

	//все пользователи будут создаваться по-умолчанию с ролью user,
	//только root может менять роль другого пользователя

	//создаем роль для пользователя root
	$role = $auth->createRole('root');
	//наследуем операции, определённые для admin'а и добавляем новые
	$role->addChild('admin');
	$role->addChild('updateUser');
	$role->addChild('deleteUser');
	$role->addChild('changeRole');

	//создаем операции для user'а
	$bizRule='return Yii::app()->user->id==$params["contact"]->c_user_id;';

	$auth->createOperation('createContact','создание контакта');
	$auth->createOperation('viewContacts','просмотр списка контактов');
	$auth->createOperation('readContact','просмотр контакта', $bizRule);
	$auth->createOperation('updateContact','редактирование контакта',$bizRule);
	$auth->createTask('deleteContact','удаление контакта',$bizRule);

	//создаем роль user и добавляем операции для неё
	$user = $auth->createRole('user');

	$user->addChild('createContact');
	$user->addChild('viewContacts');
	$user->addChild('readContact');
	$user->addChild('updateContact');
	$user->addChild('deleteContact');
	$user->addChild('updateOwnData');

	//создаем пользователя root (запись в БД в таблице users)
	//тут используем DAO, т.к. AR автоматически назначит пользователю роль user
	$sql = 'INSERT INTO users(u_name, u_email, u_pass, u_state, u_role)'
		.' VALUES ("root", "test@test.ru", "'.md5('11111')
		.'", '.Users::STATE_ACTIVE.', "'.Users::ROLE_ROOT.'")';
	$conn = Yii::app()->db;
	$conn->createCommand($sql)->execute();

	//связываем пользователя с ролью
	$auth->assign('root', $conn->getLastInsertID());

	//сохраняем роли и операции
	$auth->save();

	$this->render('install');
}

Метод получился довольно объемный, но в нём большую часть занимаю вызовы createOperation и addChild, которые создают операции и связывают их с ролями.

Большинство операций в этом примере соответствуют методам контроллера (CRUD), но они могут быть любыми. Например, такими как changeRole, позволяющими изменять одно единственное поле записи.

Обратите внимание. После создания операций и ролей доступ ограничен не будет. Вы должны будете сами проверить у пользователя наличие прав с помощью метода checkAccess.

Отдельного внимания заслуживает использование бизнес правил (bizRule) в операциях.

Бизнес правило представляет собой обычный PHP код, который должен возвращать true или false. Этот код может получить массив с данными, который будет доступен через переменную $params.

Рассмотрим правило

$bizRule='return Yii::app()->user->id==$params["user"]->u_id;';

Здесь мы проверяем, соответствуют ли id текущего пользователя (который выполнил вход) и id записи в таблице пользователей, которую он хочет изменить. Таким образом, это правило позволит пользователю редактировать только свои данные.

В конце метода мы создаём пользователя root. Дело в том, что все пользователи будут создаваться с ролью user и только root может изменять роль. Поэтому мы создаём его сразу при инсталляции.

После создания пользователя назначаем ему роль (метод assign) и сохраняем изменения
$auth->save();

Шаг четвертый. Создание модели для работы с пользователями.

Как обычно, создаём модель с помощью генератора (gii) и затем вносим свои изменения.

Весь код модели я приводить здесь не буду (в конце статьи есть ссылка на архив с примером). Рассмотрим только измененные методы.

public function beforeSave() {
	parent::beforeSave();
	$this->u_pass = md5($this->u_pass);
	/*
	 * Если пользователь не имеет права изменять роль, то мы должны
	 * установить роль по-умолчанию (user)
	 */
	if (!Yii::app()->user->checkAccess('changeRole')) {
		if ($this->isNewRecord) {
			//ставим роль по-умолчанию user
			$this->u_role = Users::ROLE_USER;
		}
	}
	return true;
}

Перед созданием новой записи мы проверяем, имеет ли текущей пользователь право изменять роли, если нет, то ставим роль по-умолчанию (user).

После сохранения (или создания) записи, нужно назначить пользователю роль. Права пользователя мы уже проверили и роль установили, поэтому сейчас просто назначаем пользователю роль (метод assign).

Предварительно, с помощью метода revoke удаляем связь между пользователем и ролью (если такая существовала). Если связь не удалить, то когда root будет изменять роли, у нас появятся пользователи с несколькими ролями.

public function afterSave() {
	parent::afterSave();
	//связываем нового пользователя с ролью
	$auth=Yii::app()->authManager;
	//предварительно удаляем старую связь
	$auth->revoke($this->prevRole, $this->u_id);
	$auth->assign($this->u_role, $this->u_id);
	$auth->save();
	return true;
}

При удалении пользователя не забываем удалить связь между ним и ролью.

public function beforeDelete() {
	parent::beforeDelete();
	//убираем связь удаленного пользователя с ролью
	$auth=Yii::app()->authManager;
	$auth->revoke($this->u_role, $this->u_id);
	$auth->save();
	return true;
}

Как видите, принцип работы достаточно простой. Главное, не забывайте вызывать $auth->save(); чтобы сохранить изменения.

Шаг пятый. Контроллер и представления.

Как и в случае с моделью, создаем контроллер и представления с помощью генератора (gii).

Методы filters и accessRules можно убрать, т.к. их мы не используем. В остальные методы добавляем проверку прав пользователя.

Опять же, весь контроллер целиком рассматривать нет смысла, он есть в архиве с исходниками. В качестве примера рассмотрим метод обновления данных пользователя.

Это самый сложный случай. У нас есть пользователь, которому можно изменять любые записи, есть пользователи, которым можно изменять только свою запись, но при этом нельзя изменять свою роль. Поэтому проверок будет две.

В первый раз проверяем, пытается ли изменить роль пользователь, у которого на это нет прав.

С помощью второй проверки убеждаемся, что у пользователя есть права на изменение данной записи.

public function actionUpdate()
{
	$model=$this->loadModel();

	//проверяем, можно ли пользователю изменять роль
	if (isset($_POST['Users']['u_role']) && !Yii::app()->user->checkAccess('changeRole')) {
		throw new CHttpException(403,'Forbidden');
	}

	//проверяем, может ли пользователь изменять данную запись
	if (!Yii::app()->user->checkAccess('updateUser')
			&& !Yii::app()->user->checkAccess('updateOwnData', array('user'=>$model))) {
		throw new CHttpException(403,'Forbidden');
	}

	if(isset($_POST['Users']))
	{
		$model->prevRole = $model->u_role;
		$model->attributes=$_POST['Users'];
		if($model->save())
			$this->redirect(array('view','id'=>$model->u_id));
	}

	$this->render('update',array(
		'model'=>$model,
	));
}

В представлении (views/users/_form.php) убираем из формы поле «Роль» для пользователя у которого нет прав её изменять.

…
<?php if (Yii::app()->user->checkAccess('changeRole')) { ?>
	<div class="row">
		<?php echo $form->labelEx($model,'u_role'); ?>
		<?php echo $form->dropDownList($model,'u_role',array(
				Users::ROLE_USER=>Users::ROLE_USER,
				Users::ROLE_ADMIN=>Users::ROLE_ADMIN,
				Users::ROLE_ROOT=>Users::ROLE_ROOT,
			));
		?>
		<?php echo $form->error($model,'u_role'); ?>
	</div>
<?php } ?>
…

На этом мы остановимся. Общую идею, надеюсь, я объяснил. Если есть желание, можете скачать архив и поиграться с этим примером.

В архиве есть дамп базы и папка protected приложения. Само приложение вам нужно будет создать самостоятельно. Дальше, думаю, вы разберетесь

Любые вопросы или замечания оставляйте в комментариях. Постараюсь ответить!