До сих пор я разрабатывал веб-приложения с использованием Yii 1.1.14, но теперь пришло время для обновления.
Компания, в которой я работаю, разработала собственную систему контроля доступа, и с ней все было в порядке, пока я не увидел, что это было на самом деле … Комбинация из 8 таблиц в базе данных (не считая таблицы пользователей), с пучком внешних ключей.
Это хорошо работает, но, на мой взгляд, очень важно сохранить все эти таблицы, и в какой-то момент, когда ваше приложение выходит в интернет, если оно попадает на определенное количество пользователей, оно может стать очень медленным. потому что две из этих таблиц имеют первичный ключ таблицы пользователя как внешний ключ.
Поэтому я решил, что, когда я начну разработку на Yii 2, я собираюсь начать использовать RBAC, поэтому начал искать учебники онлайн … Только нахождение множества разных версий одного и того же кода с ролью автора и разрешений для создавать или обновлять сообщения.
Я нашел комбинацию из 5 видео на Youtube, но они касаются Yii 1 RBAC. Они были полезны, потому что мне удалось понять большую часть функциональности RBAC, но у меня все еще есть некоторые сомнения, которые я буду перечислять ниже. И имейте в виду, что для этой системы контроля доступа я использую класс DBManager .
Мои сомнения
У RBI Yii 1 было 3 таблицы: auth_assignment , auth_item и auth_item_child . Теперь в Yii 2 RBAC появляется новая таблица, которая называется auth_rule и я до сих пор не понимаю, что делает эта конкретная таблица, как ее использовать или как ее заполнять.
Я вижу, что можно ограничить доступ пользователя к некоторым действиям с помощью метода поведения контроллера и назначить доступ к некоторым действиям в зависимости от роли пользователя, но когда дело доходит до этого, я должен разделить свой вопрос на 2:
2.1. Во-первых: Если вы можете просто ограничить доступ к действиям, настроив его в методе поведения, то в чем auth_item сохранения разрешений для таблицы auth_item ?
2.2. Во-вторых: если вы решили контролировать доступ в соответствии с разрешениями, то как именно вы это делаете, потому что я нахожу, что я пишу следующий код внутри каждой функции, и я не думаю, что использование RBAC должно быть утомительным. Должен быть другой путь.
public function actionView($id) { if(Yii::$app->user->can('view-users')){ return $this->render('view', [ 'model' => $this->findModel($id), ]); }else{ #Redirect to a custom made action that will show a view #with a custom error message $this->redirect(['//site/notauthorized']); } }
Из-за системы контроля доступа, которую мы используем прямо сейчас, когда пользователь входит в систему, выполняется сложный запрос, который вернет массив, который будет сохранен как переменная сеанса, и будет использоваться для создания меню с таким количеством dropdownlists как категории меню, к которым принадлежат контроллеры, к которым пользователь имеет доступ. Как это можно сделать с RBAC?
Я могу только ответить на 2.2 вашего вопроса, так как 3 вообще не звучит, как что-то, что должен сделать RBAC. Однако вы могли бы получить нужную вам информацию из таблицы правил, если бы вы следовали соглашению об именах, которое соответствовало вашим контроллерам или действиям.
На вопрос 2.2, хотя:
Вы можете просто настроить поведение следующим образом:
public function behaviors() { return [ 'access' => [ 'class' => AccessControl::className(), 'rules' => [ [ 'allow' => true, 'actions' => ['view'], 'roles' => ['view-users'], //<-- Note, rule instead of role ], ] ] }
Это не решает другую проблему разрешений стиля «view-own-users», так как это необходимо для проверки модели ActiveRecord (ну, по крайней мере, в моем приложении). Если вы хотите этого достичь, взгляните на мой пост на форумах Yii:
Я использую его в одном из простейших методов, я использую их в поведении моего контроллера.
public function behaviors() { return [ 'access' => [ 'class' => \yii\filters\AccessControl::className(), 'rules' => [ [ 'allow' => true, 'roles' => ['sysadmin'], 'actions' => ['index','view','update'], ], [ 'allow' => true, 'roles' => ['staff'], 'actions' => ['index','create','update','view'], ], ], ], ]; }
Здесь роли – это те, которые были созданы в таблице auth-item в базе данных, и они были назначены для пользователей в таблице присвоения полномочий. В поведении мы просто используем его, как указано выше. В приведенном выше коде sysadmin может иметь доступ к действию индекса, просмотра и обновления, тогда как сотрудники могут иметь доступ к указанию, созданию, обновлению и просмотру действий.
Yii2 нуждается в небольшой настройке, когда дело доходит до использования RBAC под вашими контроллерами AccessControl. Я обошел его, создав свой собственный файл AccessRule.
namespace app\components; use Yii; class AccessRule extends \yii\filters\AccessRule { protected function matchRole($user) { if (empty($this->roles)) { return true; } foreach ($this->roles as $role) { if(Yii::$app->authManager->checkAccess($user->identity->code, $role)) return true; } return false; }
то в вашем контроллере вы можете использовать что-то вроде этого:
public function behaviors() { return [ 'access' => [ 'class' => AccessControl::className(), 'ruleConfig' => [ 'class' => 'app\components\AccessRule' ], 'rules' => [ [ 'actions' => ['index', 'resource-type'], 'allow'=> true, 'roles' => ['admin'], ], ], ], ]; }
Где admin определяется как auth_item, а пользователь находится в параметрах auth_item_assignments.
Поскольку я создал новую систему Rbac для yii2. вы можете направить разрешение на действие, и действие покажет, что вы не авторизованы для этого действия.
Таким образом вы обнаружите, что вы обеспечите доступ только для действий, которые необходимо определить.
Я загрузил свою деталь здесь, вы можете найти множество решений здесь .
Это лучшее решение, которое я мог бы придумать, когда сталкиваюсь с необходимостью фильтровать доступ по разрешениям, это надоедливо, но может быть полезно, если вы пытаетесь создать роли в продуктивной среде и хотите использовать rbac.
use yii\web\ForbiddenHttpException; if(Yii::$app->user->can('view-users')){ return $this->render('view', [ 'model' => $this->findModel($id), ]); }else{ throw new ForbiddenHttpException('You dont have access to this site'); }