mirror of
https://github.com/yiisoft/yii2.git
synced 2025-11-03 22:32:40 +08:00
Merge pull request #8378 from miramir/fix_typo
Fix translation in authorization docs [ci skip]
This commit is contained in:
Alexander Makarov
@ -1,11 +1,11 @@
|
||||
Аутентификация
|
||||
==============
|
||||
|
||||
Аутентификация это процесс проверки подлинности пользователя. Обычно используется идентификатор
|
||||
Аутентификация - это процесс проверки подлинности пользователя. Обычно используется идентификатор
|
||||
(например `username` или адрес электронной почты) и секретный токен (например пароль или ключ доступа), чтобы судить о
|
||||
том что пользователь именно тот за кого себя выдаёт. Аутентификация является основной функуцией формы входа.
|
||||
|
||||
Yii обеспечивает фреймворк авторизации с различнымы компонентами обеспечивающими процесс входа.
|
||||
Yii обеспечивает фреймворк авторизации с различнымы компонентами, обеспечивающими процесс входа.
|
||||
Для использования этого фреймворка, вам нужно проделать следующее:
|
||||
|
||||
* Настроить компонент приложения [[yii\web\User|user]];
|
||||
@ -38,12 +38,12 @@ return [
|
||||
* [[yii\web\IdentityInterface::findIdentity()|findIdentity()]]: Этот метод находит экземпляр `identity class`,
|
||||
используя ID пользователя. Этот метод используется, когда необходимо поддерживать состояние аутентификации через сессии.
|
||||
* [[yii\web\IdentityInterface::findIdentityByAccessToken()|findIdentityByAccessToken()]]: Этот метод находит экземпляр `identity class`,
|
||||
используя токен доступа. Этот метод используется когда нужно аутентифицировать пользователя
|
||||
по единственному секретному токену (например в RESTful приложениях, не сохраняющих состояние между запросами).
|
||||
* [[yii\web\IdentityInterface::getId()|getId()]]: Этот метод возвращает ID пользователя представленного данным экземпляром `identity`.
|
||||
* [[yii\web\IdentityInterface::getAuthKey()|getAuthKey()]]: Этот метод возвращает ключ используемый для основанной на `cookie` аутентификации.
|
||||
используя токен доступа. Этот метод используется, когда нужно аутентифицировать пользователя
|
||||
по одному секретному токену (например в RESTful приложениях, не сохраняющих состояние между запросами).
|
||||
* [[yii\web\IdentityInterface::getId()|getId()]]: Этот метод возвращает ID пользователя, представленного данным экземпляром `identity`.
|
||||
* [[yii\web\IdentityInterface::getAuthKey()|getAuthKey()]]: Этот метод возвращает ключ, используемый для основанной на `cookie` аутентификации.
|
||||
Ключ сохраняется в аутентификационной cookie и позже сравниватеся с версией находящейся на сервере,
|
||||
чтоб удостоверится что аутентификационная `cookie` верная.
|
||||
чтобы удостоверится что аутентификационная `cookie` верная.
|
||||
* [[yii\web\IdentityInterface::validateAuthKey()|validateAuthKey()]]: Этот метод реализует логику проверки ключа
|
||||
для основанной на `cookie` аутентификации.
|
||||
|
||||
@ -117,7 +117,7 @@ class User extends ActiveRecord implements IdentityInterface
|
||||
}
|
||||
```
|
||||
|
||||
Как обьяснялось ранее, вам нужно реализовать только `getAuthKey()` и `validateAuthKey()` если ваше приложение использует
|
||||
Как обьяснялось ранее, вам нужно реализовать только `getAuthKey()` и `validateAuthKey()`, если ваше приложение использует
|
||||
только аутентификацию основанную на `cookie`. В этом случае, вы можете использовать следующий код для генерации
|
||||
ключа аутентификации для каждого пользователя и хранения его в таблице `user`:
|
||||
|
||||
@ -141,7 +141,7 @@ class User extends ActiveRecord implements IdentityInterface
|
||||
|
||||
> Замечание: Не путайте `identity` класс `User` с классом [[yii\web\User]]. Первый является классом реализующим
|
||||
логику аутентификации пользователя. Он часто реализуется как класс [Active Record](db-active-record.md) связанный
|
||||
с некоторым постоянным хранилищем где лежит информация о пользователях. Второй, это класс компонента приложения
|
||||
с некоторым постоянным хранилищем, где лежит информация о пользователях. Второй, это класс компонента приложения,
|
||||
отвечающий за управление состоянием аутентификации пользователя.
|
||||
|
||||
|
||||
@ -149,16 +149,16 @@ class User extends ActiveRecord implements IdentityInterface
|
||||
|
||||
В основном класс [[yii\web\User]] используют как компонент приложения `user`.
|
||||
|
||||
Можно получить `identity` текущего пользователя используя выражение `Yii::$app->user->identity`. Оно вернёт экземпляр
|
||||
[[yii\web\User::identityClass|identity class]] представляющий текущего аутентифицированного пользователя,
|
||||
или `null` если текущий пользователь не аутентифицирован (например гость). Следующий код показывает как получить
|
||||
Можно получить `identity` текущего пользователя, используя выражение `Yii::$app->user->identity`. Оно вернёт экземпляр
|
||||
[[yii\web\User::identityClass|identity class]], представляющий текущего аутентифицированного пользователя,
|
||||
или `null`, если текущий пользователь не аутентифицирован (например гость). Следующий код показывает как получить
|
||||
другую связанную с аутентификацией информацию из [[yii\web\User]]:
|
||||
|
||||
```php
|
||||
// `identity` текущего пользователя. `Null` если пользователь не аутентифицирован.
|
||||
// `identity` текущего пользователя. `Null`, если пользователь не аутентифицирован.
|
||||
$identity = Yii::$app->user->identity;
|
||||
|
||||
// ID текущего пользователя. `Null` если пользователь не аутентифицирован.
|
||||
// ID текущего пользователя. `Null`, если пользователь не аутентифицирован.
|
||||
$id = Yii::$app->user->id;
|
||||
|
||||
// проверка на то, что текущий пользователь гость (не аутентифицирован)
|
||||
@ -180,10 +180,10 @@ Yii::$app->user->login($identity);
|
||||
[[yii\web\User::enableSession|включены]], то `identity` будет сохраняться в сессии, так что состояние
|
||||
статуса аутентификации будет поддерживаться на всём протяжении сессии. Если основанный на cookie вход
|
||||
(так называемый "запомни меня" вход) [[yii\web\User::enableAutoLogin|включен]], то `identity` также будет сохранена
|
||||
в `cookie` так чтобы статус аутентификации пользователя мог быть восстановлен на протяжении всего времени жизни `cookie`.
|
||||
в `cookie` так чтобы статус аутентификации пользователя может быть восстановлен на протяжении всего времени жизни `cookie`.
|
||||
|
||||
Для включения входа основанного на `cookie`, вам нужно установить [[yii\web\User::enableAutoLogin]] в `true`
|
||||
в конфигурации приложения. Вы также можете настроить время жизни передав его при вызове метода [[yii\web\User::login()]].
|
||||
в конфигурации приложения. Вы также можете настроить время жизни, передав его при вызове метода [[yii\web\User::login()]].
|
||||
|
||||
Для выхода пользователя, просто вызовите
|
||||
|
||||
@ -193,7 +193,7 @@ Yii::$app->user->logout();
|
||||
|
||||
Обратите внимание: выход пользователя имеет смысл только если сессии включены. Метод сбрасывает статус аутентификации
|
||||
сразу и из памяти и из сессии. И по умолчанию, будут также уничтожены *все* сессионные данные пользователя.
|
||||
Если вы хотите сохранить сессионные данные, вы должны вызвать `Yii::$app->user->logout(false)`, вместо этого.
|
||||
Если вы хотите сохранить сессионные данные, вы должны вместо этого вызвать `Yii::$app->user->logout(false)`.
|
||||
|
||||
|
||||
## События аутентификации <span id="auth-events"></span>
|
||||
|
||||
@ -10,7 +10,7 @@
|
||||
Фильтры контроля доступа
|
||||
------------------------
|
||||
|
||||
Фильтры контроля доступа (ACF) является простым методом, который лучше всего использовать в приложениях с простым
|
||||
Фильтры контроля доступа (ACF) являются простым методом, который лучше всего использовать в приложениях с простым
|
||||
контролем доступа. Как указывает его название, ACF это фильтры, который может присоединяться к контроллеру
|
||||
или модулю как поведение. ACF проверяет набор [[yii\filters\AccessControl::rules|правил доступа]], чтоб убедится,
|
||||
что пользователь имеет доступ к запрошенной операции.
|
||||
@ -47,7 +47,7 @@ class SiteController extends Controller
|
||||
}
|
||||
```
|
||||
|
||||
Код выше показывет ACF прикреплённы через поведение контроллера `site`. Это типичный способ использования фильтра действий.
|
||||
Код выше показывет ACF связанный с контроллером `site` через поведение. Это типичный способ использования фильтров действий.
|
||||
Параметр `only` указывает, что фильтр ACF нужно применять только к действиям `login`, `logout` и `signup`.
|
||||
Параметр `rules` задаёт [[yii\filters\AccessRule|правила доступа]], которые означают следующее:
|
||||
|
||||
@ -60,50 +60,50 @@ class SiteController extends Controller
|
||||
Значение опции `allow` выбранного правила указывает авторизовывать пользователя или нет. Если ни одно из правил
|
||||
не совпало, то пользователь считается НЕ авторизованным и ACF останавливает дальнейшее выполнение деиствия.
|
||||
|
||||
По умолчанию, ACF когда у пользователя отсутствует доступ к текущему действию, делает следующее:
|
||||
По умолчанию, ACF, когда у пользователя отсутствует доступ к текущему действию, делает следующее:
|
||||
|
||||
* Если пользователь гость, вызывается [[yii\web\User::loginRequired()]], который перенаправляет браузер на страницу входа.
|
||||
* Если пользователь авторизован, генерируется исключение [[yii\web\ForbiddenHttpException]].
|
||||
|
||||
Вы можете переопределить это поведение настроив свойство [[yii\filters\AccessControl::denyCallback]]:
|
||||
Вы можете переопределить это поведение, настроив свойство [[yii\filters\AccessControl::denyCallback]]:
|
||||
|
||||
```php
|
||||
[
|
||||
'class' => AccessControl::className(),
|
||||
'denyCallback' => function ($rule, $action) {
|
||||
throw new \Exception('You are not allowed to access this page');
|
||||
throw new \Exception('У вас нет доступа к этой странице');
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
[[yii\filters\AccessRule|Правила доступа]] поддерживает набор свойств. Ниже краткое описание поддерживаемых опций.
|
||||
[[yii\filters\AccessRule|Правила доступа]] поддерживают набор свойств. Ниже краткое описание поддерживаемых опций.
|
||||
Вы также можете расширить [[yii\filters\AccessRule]], чтоб создать свой собственный класс правил доступа.
|
||||
|
||||
* [[yii\filters\AccessRule::allow|allow]]: указывает, что это "allow" или "deny" правило.
|
||||
* [[yii\filters\AccessRule::allow|allow]]: задаёт какое это правило, "allow" или "deny".
|
||||
|
||||
* [[yii\filters\AccessRule::actions|actions]]: указывает какие действия соответствуют этому правилу.
|
||||
Это должен быть массив идентификаторов действий. Сравнение регисрозависимо. Если данное свойство пустое или не задано,
|
||||
говорит что данное правило применяется ко всем действиям.
|
||||
* [[yii\filters\AccessRule::actions|actions]]: задаёт действия соответствующие этому правилу.
|
||||
Значение должно быть массивом идентификаторов действий. Сравнение регисрозависимо. Если свойство пустое или не задано,
|
||||
то правило применяется ко всем действиям.
|
||||
|
||||
* [[yii\filters\AccessRule::controllers|controllers]]: задаёт контроллеры, которым соответствует данное правило.
|
||||
Это должен быть массив с идентификаторами контроллеров. Сравнение регисрозависимо. Если данное свойство пустое или не задано,
|
||||
то данное правило применяется ко всем действиям.
|
||||
* [[yii\filters\AccessRule::controllers|controllers]]: задаёт контроллеры, которым соответствует правило.
|
||||
Значение должно быть массивом с идентификаторами контроллеров. Сравнение регисрозависимо. Если свойство
|
||||
пустое или не задано, то правило применяется ко всем действиям.
|
||||
|
||||
* [[yii\filters\AccessRule::roles|roles]]: задаёт роли пользователей соответствующих данному правилу.
|
||||
* [[yii\filters\AccessRule::roles|roles]]: задаёт роли пользователей соответствующих этому правилу.
|
||||
Распознаются две специальные роли, которые проверяются с помощью [[yii\web\User::isGuest]]:
|
||||
|
||||
- `?`: соответствует гостевому пользователю (не аутентифицирован)
|
||||
- `@`: соответствует аутентифицированному пользователю
|
||||
|
||||
Использование других имён ролей требует RBAC (будет описано дальше), можно будет использовать [[yii\web\User::can()]].
|
||||
Если данное свойство пустое или не задано, то данное правило применяется ко всем ролям.
|
||||
Использование других имён ролей будет приводить к вызову метода [[yii\web\User::can()]], который требует включения
|
||||
RBAC (будет описано дальше). Если свойство пустое или не задано, то правило применяется ко всем ролям.
|
||||
|
||||
* [[yii\filters\AccessRule::ips|ips]]: задаёт [[yii\web\Request::userIP|клиентские IP адреса]] для которых применяется это правило.
|
||||
IP адрес может содержать `*` в конце, так чтоб он соответствовал IP адресу с таким же префиксом.
|
||||
Для примера, '192.168.*' соответствует всем IP адресам в сегменте '192.168.'. Если данное свойство пустое или не задано,
|
||||
то данное правило применяется ко всем IP адресам.
|
||||
* [[yii\filters\AccessRule::ips|ips]]: задаёт [[yii\web\Request::userIP|IP адреса пользователей]], для которых применяется
|
||||
это правило. IP адрес может содержать `*` в конце, так чтобы он соответствовал IP адресу с таким же префиксом.
|
||||
Для примера, '192.168.*' соответствует всем IP адресам в сегменте '192.168.'. Если свойство пустое или не задано,
|
||||
то правило применяется ко всем IP адресам.
|
||||
|
||||
* [[yii\filters\AccessRule::verbs|verbs]]: задаёт http метод (например `GET`, `POST`) соответствующий данному правилу.
|
||||
* [[yii\filters\AccessRule::verbs|verbs]]: задаёт http метод (например `GET`, `POST`) соответствующий правилу.
|
||||
Сравнение регисронезависимо.
|
||||
|
||||
* [[yii\filters\AccessRule::matchCallback|matchCallback]]: задаёт PHP колбек, который вызывается для определения,
|
||||
@ -112,7 +112,7 @@ IP адрес может содержать `*` в конце, так чтоб
|
||||
* [[yii\filters\AccessRule::denyCallback|denyCallback]]: задаёт PHP колбек, который будет вызван если доступ будет
|
||||
запрещён при вызове этого правила.
|
||||
|
||||
Ниже покзан пример, который показывает использование опции `matchCallback`, которая позволяет писать произвольную
|
||||
Ниже покзан пример, показывающий использование опции `matchCallback`, которая позволяет писать произвольную
|
||||
логику проверки доступа:
|
||||
|
||||
```php
|
||||
@ -152,28 +152,28 @@ class SiteController extends Controller
|
||||
---------------------------------------
|
||||
|
||||
Управление доступом на основе ролей (RBAC) обеспечивает простой, но мощьный централизованный контроль доступа.
|
||||
Пожалуйста обратитесь к [Wikipedia](http://en.wikipedia.org/wiki/Role-based_access_control) для получения более
|
||||
подробного сравнения RBAC с другими более традиционными системами контроля доступа.
|
||||
Пожалуйста обратитесь к [Wikipedia](https://ru.wikipedia.org/wiki/%D0%A3%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B4%D0%BE%D1%81%D1%82%D1%83%D0%BF%D0%BE%D0%BC_%D0%BD%D0%B0_%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B5_%D1%80%D0%BE%D0%BB%D0%B5%D0%B9)
|
||||
для получения более подробного сравнения RBAC с другими, более традиционными, системами контроля доступа.
|
||||
|
||||
Yii реализует общую иерархическую RBAC, следуя [NIST RBAC model](http://csrc.nist.gov/rbac/sandhu-ferraiolo-kuhn-00.pdf).
|
||||
Обеспечивается функциональность RBAC через [[yii\rbac\ManagerInterface|authManager]] [компонент приложения](structure-application-components.md).
|
||||
Обеспечивается функциональность RBAC через [компонент приложения](structure-application-components.md) [[yii\rbac\ManagerInterface|authManager]].
|
||||
|
||||
Использование RBAC состоит из двух частей. Первая часть - это создание RBAC данных авторизации, и вторая часть это
|
||||
использование данных авторизации для проверки доступа в том месте где это нужно.
|
||||
Использование RBAC состоит из двух частей. Первая часть - это создание RBAC данных авторизации, и вторая часть - это
|
||||
использование данных авторизации для проверки доступа в том месте, где это нужно.
|
||||
|
||||
Для облегчения последующего описания, мы сначала введём некоторые основные понятия RBAC.
|
||||
|
||||
|
||||
### Основные концепции
|
||||
|
||||
Роль представляет собой набор *permissions* (разрешения) (например создание сообщения, обновление сообщения).
|
||||
Роль представляет собой набор разрешений (*permissions*) (например создание сообщения, обновление сообщения).
|
||||
Роль может быть назначена на одного или многих пользователей. Чтобы проверить, имеет ли пользователь указанные
|
||||
разрешения, мы можем проверить назначена ли пользователю роль, которая содержит данное разрешение.
|
||||
разрешения, мы должны проверить назначена ли пользователю роль, которая содержит данное разрешение.
|
||||
|
||||
С каждой ролью или разрешением может быть связано *rule* (правило). Правило представляет собой кусок кода, который будет
|
||||
С каждой ролью или разрешением может быть связано правило (*rule*). Правило представляет собой кусок кода, который будет
|
||||
выполняться в ходе проверки доступа для определения может ли быть применена соответствующая роль или разрешение
|
||||
к текущему пользователю. Например, разрешение "обновление поста" может иметь правило, которое проверяет является ли
|
||||
текущий пользовател автором поста. Во время проверки доступа, если пользователь не является автором поста, он/она будет
|
||||
текущий пользователь автором поста. Во время проверки доступа, если пользователь не является автором поста, он/она будет
|
||||
считаться не имеющими разрешения "обновление поста".
|
||||
|
||||
И роли и разрешения могут быть организованы в иерархию. В частности роль может содержать другие роли или разрешения; и
|
||||
@ -183,10 +183,11 @@ Yii реализует общую иерархическую RBAC, следуя
|
||||
|
||||
### Настройка RBAC Manager
|
||||
|
||||
Перед определением авторизационных данных и проверкой прав доступа, мы должны настроить компонент приложения [[yii\base\Application::authManager|authManager]].
|
||||
Yii предоставляет два типа менеджеров авторизации: [[yii\rbac\PhpManager]] и [[yii\rbac\DbManager]]. Первый использует
|
||||
файл с PHP скриптом для хранения данных авторизации, второй сохраняет данные в базе данных. Вы можете использовать
|
||||
первый если ваше приложение не требует слишком динамичным управлением ролями и разрешениями.
|
||||
Перед определением авторизационных данных и проверкой прав доступа, мы должны настроить компонент приложения
|
||||
[[yii\base\Application::authManager|authManager]]. Yii предоставляет два типа менеджеров авторизации:
|
||||
[[yii\rbac\PhpManager]] и [[yii\rbac\DbManager]]. Первый использует файл с PHP скриптом для хранения данных авторизации,
|
||||
второй сохраняет данные в базе данных. Вы можете использовать первый если ваше приложение не требует слишком динамичного
|
||||
управления ролями и разрешениями.
|
||||
|
||||
#### настройка authManager с помощью `PhpManager`
|
||||
|
||||
@ -225,14 +226,14 @@ return [
|
||||
];
|
||||
```
|
||||
|
||||
`DbManager` использует четыре таблицы базы данных для хранения данных:
|
||||
`DbManager` использует четыре таблицы для хранения данных:
|
||||
|
||||
- [[yii\rbac\DbManager::$itemTable|itemTable]]: таблица для хранения авторизационных элементов. По умолчанию "auth_item".
|
||||
- [[yii\rbac\DbManager::$itemChildTable|itemChildTable]]: таблица для хранения иерархии элементов. По умолчанию "auth_item_child".
|
||||
- [[yii\rbac\DbManager::$assignmentTable|assignmentTable]]: таблица для хранения назначений элементов авторизации. По умолчанию "auth_assignment".
|
||||
- [[yii\rbac\DbManager::$ruleTable|ruleTable]]: таблица для хранения правил. По умолчанию "auth_rule".
|
||||
|
||||
Прежде чем вы начнёте его использовать вам нужно создать эти таблицы в базе данных. Чтобы сделать это,
|
||||
Прежде чем вы начнёте использовать этот менеджер, вам нужно создать таблицы в базе данных. Чтобы сделать это,
|
||||
вы можете использовать миграцию хранящуюся в файле `@yii/rbac/migrations`:
|
||||
|
||||
`yii migrate --migrationPath=@yii/rbac/migrations`
|
||||
@ -241,13 +242,13 @@ return [
|
||||
|
||||
### Создание данных авторизации
|
||||
|
||||
Создание данных авторизации это следущие задачи:
|
||||
Для создания данных авторизации нужно выполнить следущие задачи:
|
||||
|
||||
- определение ролей и разрешений;
|
||||
- установка отношений между ролями и правами доступа;
|
||||
- определение правил;
|
||||
- связывание правил с ролями и разрешениями;
|
||||
- назначение ролей с пользователями.
|
||||
- назначение ролей пользователям.
|
||||
|
||||
В зависимости от требований к гибкости авторизации перечисленные задачи могут быть выполнены разными путями.
|
||||
|
||||
@ -305,7 +306,7 @@ class RbacController extends Controller
|
||||
Автор может создавать пост, администратор может обновлять пост и делать всё, что может делать автор.
|
||||
|
||||
Если ваше приложение позволяет регистрировать пользователей, то вам необходимо сразу назначать роли этим новым пользователям.
|
||||
Например, для того, чтобы все вошедшие пользователи могли стать авторами в расширеном шаблоне проекта вы должны изменить
|
||||
Например, для того, чтобы все вошедшие пользователи могли стать авторами в расширеном шаблоне проекта, вы должны изменить
|
||||
`frontend\models\SignupForm::signup()` как показано ниже:
|
||||
|
||||
```php
|
||||
@ -338,8 +339,8 @@ public function signup()
|
||||
|
||||
### Использование правил
|
||||
|
||||
Как упомянуто выше, правила добавляют дополнительные ограничение на роли и разрешения. Правило это классы, расширяющие
|
||||
[[yii\rbac\Rule]]. Он должен реализовывать метод [[yii\rbac\Rule::execute()|execute()]]. В иерархии созданой нами ранее
|
||||
Как упомянуто выше, правила добавляют дополнительные ограничения на роли и разрешения. Правила это классы, расширяющие
|
||||
[[yii\rbac\Rule]]. Они должны реализовывать метод [[yii\rbac\Rule::execute()|execute()]]. В иерархии, созданой нами ранее,
|
||||
автор не можете редактировать свой пост. Давайте исправим это. Во-первых, мы должны создать правило проверяющее,
|
||||
что пользователь является автором поста:
|
||||
|
||||
@ -397,7 +398,7 @@ $auth->addChild($author, $updateOwnPost);
|
||||
|
||||
### Проверка доступа
|
||||
|
||||
С готовыми данными авторизациями проверка доступа это просто вызов метода [[yii\rbac\ManagerInterface::checkAccess()]].
|
||||
С готовыми авторизационными данными, проверка доступа - это просто вызов метода [[yii\rbac\ManagerInterface::checkAccess()]].
|
||||
Так как большинство проверок доступа относятся к текущему пользователю, для удобства Yii предоставляет сокращённый метод
|
||||
[[yii\web\User::can()]], который можно использовать как показано ниже:
|
||||
|
||||
@ -407,12 +408,12 @@ if (\Yii::$app->user->can('createPost')) {
|
||||
}
|
||||
```
|
||||
|
||||
Если текущий пользователь Jane с ID=1 мы начнём с `createPost` и попробуем добраться до `Jane`:
|
||||
Если текущий пользователь Jane с ID=1, мы начнём с `createPost` и попробуем добраться до `Jane`:
|
||||
|
||||
|
||||
|
||||
Для того чтоб проверить может ли пользователь обновить пост, нам надо передать дополнительный параметр
|
||||
необходимый для правила `AuthorRule` описанного ранее:
|
||||
Для того чтоб проверить может ли пользователь обновить пост, нам надо передать дополнительный параметр,
|
||||
необходимый для правила `AuthorRule`, описанного ранее:
|
||||
|
||||
```php
|
||||
if (\Yii::$app->user->can('updatePost', ['post' => $post])) {
|
||||
@ -424,9 +425,9 @@ if (\Yii::$app->user->can('updatePost', ['post' => $post])) {
|
||||
|
||||
|
||||
|
||||
Мы начинаем с `updatePost` и переходим к `updateOwnPost`. Для того чтоб это произошло правило `AuthorRule` должен вернуть
|
||||
Мы начинаем с `updatePost` и переходим к `updateOwnPost`. Для того чтоб это произошло, правило `AuthorRule` должно вернуть
|
||||
`true` при вызове метода `execute`. Метод получает `$params` переданный при вызове метода `can`, значение которого равно
|
||||
`['post' => $post]`. Если всё правильно мы понимаем что `author` привязан к John.
|
||||
`['post' => $post]`. Если всё правильно мы увидим, что `author` привязан к John.
|
||||
|
||||
В случае Jane это немного проще, потому что она admin:
|
||||
|
||||
@ -434,18 +435,18 @@ if (\Yii::$app->user->can('updatePost', ['post' => $post])) {
|
||||
|
||||
### Использование роли по умолчанию
|
||||
|
||||
Роль по умолчанию это роль, которая *неявно* присваивается *всем* пользователям. Вызов метода
|
||||
Роль по умолчанию - это роль, которая *неявно* присваивается *всем* пользователям. Вызов метода
|
||||
[[yii\rbac\ManagerInterface::assign()]] не требуется, и авторизационные данные не содержат информации о назначении.
|
||||
|
||||
Роль по умолчанию обычно связывают с правилом определяющим к какой роли принадлежит каждый пользователь.
|
||||
|
||||
Роли по умолчанию обычно используются в приложениях, которые уже имеют какое-то назначение ролей. Для примера, приложение
|
||||
может иметь столбец "group" в таблице пользователей и каждый пользователь принадлежит к какой-то группе. Если каждая
|
||||
группа может быть сопоставлена роли в RBAC, вы можете использовать роль по умолчанию для автоматического назначения
|
||||
Роли по умолчанию обычно используются в приложениях, которые уже имеют какое-то описание ролей. Для примера, приложение
|
||||
может иметь столбец "group" в таблице пользователей, и каждый пользователь принадлежит к какой-то группе. Если каждая
|
||||
группа может быть сопоставлена роли в модели RBAC, вы можете использовать роль по умолчанию для автоматического назначения
|
||||
каждому пользователю роли RBAC. Давайте используем пример, чтобы понять как это можно сделать.
|
||||
|
||||
Предположим что в таблице пользователей у вам есть столбец `group`, в котором значение 1 представляет группу "администратор",
|
||||
а 2 - группу "автор". Вы планируете иметь 2 RBAC роли `admin` и `author` представляющими разрешения для двух
|
||||
Предположим что в таблице пользователей у вас есть столбец `group`, в котором значение 1 представляет группу "администратор",
|
||||
а 2 - группу "автор". Вы планируете иметь две RBAC роли `admin` и `author`, представляющие разрешения для двух
|
||||
соответствующих групп. Вы можете настроить данные роли как показано ниже.
|
||||
|
||||
```php
|
||||
@ -493,7 +494,7 @@ $auth->addChild($admin, $author);
|
||||
```
|
||||
|
||||
Обратите внимание, так как "author" добавлен как дочерняя роль к "admin", следовательно в реализации метода `execute()`
|
||||
класса правила вы должны учитывать это иерархию. Именно по этому для роли "author" метод `execute()` вернёт истину
|
||||
класса правила вы должны учитывать эту иерархию. Именно по этому для роли "author" метод `execute()` вернёт истину,
|
||||
если пользователь принадлежит к группам 1 или 2 (это означает, что пользователь находится в группе
|
||||
администраторов или авторов)
|
||||
|
||||
@ -512,7 +513,7 @@ return [
|
||||
];
|
||||
```
|
||||
|
||||
Теперь если вы выполните проверку доступа, для обойх ролей `admin` и `author` будет выполнена проверка правила
|
||||
Теперь, если вы выполните проверку доступа, для обойх ролей `admin` и `author` будет выполнена проверка правила
|
||||
асоциированного с ними. Если правило вернёт истину, это будет означать что роль применяется к текущему пользователю.
|
||||
На основании правила, реализованного выше, если пользователь входит в группу 1 пользователю будет назначена роль `admin`;
|
||||
и если значение `group` равно 2 будет применена роль `author`.
|
||||
|
||||
Reference in New Issue
Block a user