Fix punctuation, typos and some style

docs/guide-ru/security-authorization.md

@@ -3,19 +3,19 @@
 
 > Note: этот раздел находится на стадии разработки.
 
-Авторизация это процесс проверки того, что пользователь имеет достаточно прав чтобы что-то сделать. Yii обеспечивает два
-метода авторизации: Фильтры контроля доступа (ACF) и контроль доступа основанный на ролях (RBAC).
+Авторизация — это процесс проверки того, что пользователь имеет достаточно прав чтобы что-то сделать. Yii обеспечивает два
+метода авторизации: фильтры контроля доступа (ACF) и контроль доступа на основе ролей (RBAC).
 
 
 Фильтры контроля доступа
 ------------------------
 
 Фильтры контроля доступа (ACF) являются простым методом, который лучше всего использовать в приложениях с простым
-контролем доступа. Как указывает его название, ACF это фильтры, который может присоединяться к контроллеру
-или модулю как поведение. ACF проверяет набор [[yii\filters\AccessControl::rules|правил доступа]], чтобы убедится,
+контролем доступа. Как указывает его название, ACF — это фильтры, которые могут присоединяться к контроллеру
+или модулю как поведение. ACF проверяет набор [[yii\filters\AccessControl::rules|правил доступа]], чтобы убедиться,
 что пользователь имеет доступ к запрошенной операции.
 
-Код ниже показывает как использовать ACF реализованный в [[yii\filters\AccessControl]]:
+Код ниже показывает как использовать ACF, реализованный в [[yii\filters\AccessControl]]:
 
 ```php
 use yii\filters\AccessControl;
@@ -76,20 +76,20 @@ class SiteController extends Controller
 ]
 ```
 
-[[yii\filters\AccessRule|Правила доступа]] поддерживают набор свойств. Ниже краткое описание поддерживаемых опций.
+[[yii\filters\AccessRule|Правила доступа]] поддерживают набор свойств. Ниже дано краткое описание поддерживаемых опций.
 Вы также можете расширить [[yii\filters\AccessRule]], чтобы создать свой собственный класс правил доступа.
 
  * [[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::roles|roles]]: задаёт роли пользователей соответствующих этому правилу.
+ * [[yii\filters\AccessRule::roles|roles]]: задаёт роли пользователей, соответствующих этому правилу.
    Распознаются две специальные роли, которые проверяются с помощью [[yii\web\User::isGuest]]:
 
      - `?`: соответствует гостевому пользователю (не аутентифицирован)
@@ -104,12 +104,12 @@ class SiteController extends Controller
 то правило применяется ко всем IP адресам.
 
  * [[yii\filters\AccessRule::verbs|verbs]]: задаёт http метод (например `GET`, `POST`) соответствующий правилу.
-Сравнение регисронезависимо.
+Сравнение регистронезависимо.
 
  * [[yii\filters\AccessRule::matchCallback|matchCallback]]: задаёт PHP колбек, который вызывается для определения,
 что правило должно быть применено.
 
- * [[yii\filters\AccessRule::denyCallback|denyCallback]]: задаёт PHP колбек, который будет вызван если доступ будет
+ * [[yii\filters\AccessRule::denyCallback|denyCallback]]: задаёт PHP колбек, который будет вызван, если доступ будет
 запрещён при вызове этого правила.
 
 Ниже показан пример, показывающий использование опции `matchCallback`, которая позволяет писать произвольную
@@ -158,7 +158,7 @@ class SiteController extends Controller
 Yii реализует общую иерархическую RBAC, следуя [NIST RBAC model](http://csrc.nist.gov/rbac/sandhu-ferraiolo-kuhn-00.pdf).
 Обеспечивается функциональность RBAC через [компонент приложения](structure-application-components.md) [[yii\rbac\ManagerInterface|authManager]].
 
-Использование RBAC состоит из двух частей. Первая часть - это создание RBAC данных авторизации, и вторая часть - это
+Использование RBAC состоит из двух частей. Первая часть — это создание RBAC данных авторизации, и вторая часть — это
 использование данных авторизации для проверки доступа в том месте, где это нужно.
 
 Для облегчения последующего описания, мы сначала введём некоторые основные понятия RBAC.
@@ -166,7 +166,7 @@ Yii реализует общую иерархическую RBAC, следуя
 
 ### Основные концепции
 
-Роль представляет собой набор разрешений (*permissions*) (например создание сообщения, обновление сообщения).
+Роль представляет собой набор разрешений (*permissions*) (например, создание сообщения, обновление сообщения).
 Роль может быть назначена на одного или многих пользователей. Чтобы проверить, имеет ли пользователь указанные
 разрешения, мы должны проверить назначена ли пользователю роль, которая содержит данное разрешение.
 
@@ -176,7 +176,7 @@ Yii реализует общую иерархическую RBAC, следуя
 текущий пользователь автором поста. Во время проверки доступа, если пользователь не является автором поста, он/она будет
 считаться не имеющими разрешения "обновление поста".
 
-И роли и разрешения могут быть организованы в иерархию. В частности роль может содержать другие роли или разрешения; и
+И роли, и разрешения могут быть организованы в иерархию. В частности, роль может содержать другие роли или разрешения; и
 разрешения могут содержать другие разрешения. Yii реализует *частично упорядоченную* иерархию, которая включает в себя
 специальные *деревья* иерархии. Роль может содержать разрешение, но обратное не верно.
 
@@ -186,10 +186,10 @@ Yii реализует общую иерархическую RBAC, следуя
 Перед определением авторизационных данных и проверкой прав доступа, мы должны настроить компонент приложения
 [[yii\base\Application::authManager|authManager]]. Yii предоставляет два типа менеджеров авторизации: 
 [[yii\rbac\PhpManager]] и [[yii\rbac\DbManager]]. Первый использует файл с PHP скриптом для хранения данных авторизации,
-второй сохраняет данные в базе данных. Вы можете использовать первый если ваше приложение не требует слишком динамичного
+второй сохраняет данные в базе данных. Вы можете использовать первый, если ваше приложение не требует слишком динамичного
 управления ролями и разрешениями.
 
-#### настройка authManager с помощью `PhpManager`
+#### Настройка authManager с помощью `PhpManager`
 
 Следующий код показывает как настроить в конфигурации приложения `authManager` с использованием класса [[yii\rbac\PhpManager]]:
 
@@ -210,7 +210,7 @@ return [
 > Замечание: По умолчанию, [[yii\rbac\PhpManager]] сохраняет данные RBAC в файлах в директории `@app/rbac/`. Убедитесь
   что данная директория и файлы в них доступны для записи Web серверу, если иерархия разрешений должна меняться онлайн.
 
-#### настройка authManager с помощью `DbManager`
+#### Настройка authManager с помощью `DbManager`
 
 Следующий код показывает как настроить в конфигурации приложения `authManager` с использованием класса [[yii\rbac\DbManager]]:
 
@@ -339,9 +339,9 @@ public function signup()
 
 ### Использование правил
 
-Как упомянуто выше, правила добавляют дополнительные ограничения на роли и разрешения. Правила это классы, расширяющие
+Как упомянуто выше, правила добавляют дополнительные ограничения на роли и разрешения. Правила — это классы, расширяющие
 [[yii\rbac\Rule]]. Они должны реализовывать метод [[yii\rbac\Rule::execute()|execute()]]. В иерархии, созданной нами ранее,
-автор не может редактировать свой пост. Давайте исправим это. Во-первых, мы должны создать правило проверяющее,
+автор не может редактировать свой пост. Давайте исправим это. Сначала мы должны создать правило, проверяющее
 что пользователь является автором поста:
 
 ```php
@@ -350,7 +350,7 @@ namespace app\rbac;
 use yii\rbac\Rule;
 
 /**
- * Проверяем authorID на соответствие с пользователем переданным через параметры
+ * Проверяем authorID на соответствие с пользователем, переданным через параметры
  */
 class AuthorRule extends Rule
 {
@@ -398,7 +398,7 @@ $auth->addChild($author, $updateOwnPost);
 
 ### Проверка доступа
 
-С готовыми авторизационными данными, проверка доступа - это просто вызов метода [[yii\rbac\ManagerInterface::checkAccess()]].
+С готовыми авторизационными данными проверка доступа — это просто вызов метода [[yii\rbac\ManagerInterface::checkAccess()]].
 Так как большинство проверок доступа относятся к текущему пользователю, для удобства Yii предоставляет сокращённый метод
 [[yii\web\User::can()]], который можно использовать как показано ниже:
 
@@ -435,10 +435,10 @@ if (\Yii::$app->user->can('updatePost', ['post' => $post])) {
 
 ### Использование роли по умолчанию
 
-Роль по умолчанию - это роль, которая *неявно* присваивается *всем* пользователям. Вызов метода
+Роль по умолчанию — это роль, которая *неявно* присваивается *всем* пользователям. Вызов метода
 [[yii\rbac\ManagerInterface::assign()]] не требуется, и авторизационные данные не содержат информации о назначении.
 
-Роль по умолчанию обычно связывают с правилом определяющим к какой роли принадлежит каждый пользователь.
+Роль по умолчанию обычно связывают с правилом, определяющим к какой роли принадлежит каждый пользователь.
 
 Роли по умолчанию обычно используются в приложениях, которые уже имеют какое-то описание ролей. Для примера, приложение
 может иметь столбец "group" в таблице пользователей, и каждый пользователь принадлежит к какой-то группе. Если каждая
@@ -446,7 +446,7 @@ if (\Yii::$app->user->can('updatePost', ['post' => $post])) {
 каждому пользователю роли RBAC. Давайте используем пример, чтобы понять как это можно сделать.
 
 Предположим что в таблице пользователей у вас есть столбец `group`, в котором значение 1 представляет группу "администратор",
-а 2 - группу "автор". Вы планируете иметь две RBAC роли `admin` и `author`, представляющие разрешения для двух
+а 2 — группу "автор". Вы планируете иметь две RBAC роли `admin` и `author`, представляющие разрешения для двух
 соответствующих групп. Вы можете настроить данные роли как показано ниже.
 
 ```php
@@ -494,7 +494,7 @@ $auth->addChild($admin, $author);
 ```
 
 Обратите внимание, так как "author" добавлен как дочерняя роль к "admin", следовательно в реализации метода `execute()`
-класса правила вы должны учитывать эту иерархию. Именно по этому для роли "author" метод `execute()` вернёт истину,
+класса правила вы должны учитывать эту иерархию. Именно поэтому для роли "author" метод `execute()` вернёт истину,
 если пользователь принадлежит к группам 1 или 2 (это означает, что пользователь находится в группе 
 администраторов или авторов)
 
@@ -513,7 +513,7 @@ return [
 ];
 ```
 
-Теперь, если вы выполните проверку доступа, для обоих ролей `admin` и `author` будет выполнена проверка правила
+Теперь, если вы выполните проверку доступа, для обоих ролей `admin` и `author` будет выполнена проверка правила,
 асоциированного с ними. Если правило вернёт истину, это будет означать что роль применяется к текущему пользователю.
-На основании правила, реализованного выше, если пользователь входит в группу 1 пользователю будет назначена роль `admin`;
-и если значение `group` равно 2 будет применена роль `author`.
+На основании правила, реализованного выше, если пользователь входит в группу 1, пользователю будет назначена роль `admin`;
+и если значение `group` равно 2, будет применена роль `author`.