Глава 29. Проекционный слой

29.1. Где находится проекция

Проекция возникает между исходной моделью и проверкой запроса:

Source facts
      ↓
Security projections
      ↓
Authorization

Она нужна не для хранения копии предметной области.

Её задача — представить производные факты в форме, удобной для конкретного класса проверок.

29.2. Не вся модель должна вычисляться во время запроса

В универсальном виде можно представить авторизацию так:

Request
   ↓
findAccessGrounds()
   ↓
Rules
   ↓
Decision

Но это не обязательно означает, что findAccessGrounds() физически обходит весь граф отношений во время запроса.

В зрелой системе значительная часть результата может быть построена заранее:

Source relations
      ↓
Projection building
      ↓
Prepared access facts

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

29.3. Что происходит в Guardian

В Guardian часть access grounds материализуется заранее.

Например:

KUserGroupLink
      ↓
effective_user_group

затем:

effective_user_group
      +
role assignments
      ↓
effective_user_permission

А объектная сторона:

KPublish
      ↓
object_scope

Владелец также представлен в object_scope отдельным OWNER-scope.

Таким образом, к моменту проверки уже существует подготовленное security state.

29.4. effective_user_group

Эта проекция представляет производные отношения пользователя и групп.

Она может учитывать иерархию.

Но её назначение не в том, чтобы каждый раз отвечать:

Может ли пользователь читать объект?

Она используется при построении эффективных разрешений, в том числе при обработке Scope Barrier.

Это важное разделение:

effective_user_group
        ↓
build effective permissions

а не:

effective_user_group
        ↓
direct runtime authorization

29.5. effective_user_permission

Эта проекция уже ближе к проверке.

Она представляет производное разрешение пользователя в конкретной области:

company
user
scope_type
scope_id
permission_mask

Именно поэтому has_object_permission() может сопоставить её с:

object_scope

без повторного обхода групповой и проектной структуры.

29.6. object_scope

object_scope описывает области безопасности объекта.

Например:

OWNER
COMPANY
PROJECT
GROUP

в зависимости от конкретного основания.

Важно не смешивать область публикации с физическим размещением.

Например, owning_group_id может быть полезен как placement/storage metadata, но это не означает, что он становится входом в ACL-проверку.

Текущая объектная проверка использует:

scope_type
scope_id
permission_mask

для сопоставления с эффективным разрешением пользователя.

29.7. Почему проекции не являются ACL

Можно было бы сказать:

effective_user_permission = ACL

Но это слишком узко.

Проекция представляет производный факт.

Окончательное решение появляется только после сопоставления:

effective_user_permission
        +
object_scope
        +
required action

Поэтому:

Projection ≠ Decision

29.8. Две фазы работы

В Guardian удобно различать:

Построение security model:

Domain/security fact
      ↓
Projection update
      ↓
Prepared security state

и:

Использование security model:

Request
      ↓
has_object_permission()
      ↓
RLS
      ↓
Data

Это позволяет заранее выполнять дорогую работу и оставлять запросу короткую проверку.

29.9. Главный вывод

Проекционный слой является не оптимизацией поверх уже готовой авторизации.

Он является частью архитектуры вычисления авторизации.

Сложные отношения превращаются в производные факты заранее:

Relations
   ↓
Security projections
   ↓
Effective authorization

А запрос использует уже подготовленное состояние.