PHPackages                             illusiard/yii2-entity-acl - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Authentication & Authorization](/categories/authentication)
4. /
5. illusiard/yii2-entity-acl

ActiveYii2-extension[Authentication & Authorization](/categories/authentication)

illusiard/yii2-entity-acl
=========================

Unix-like ACL + JSON conditions (allow/deny) for entities and records in Yii2

v1.1.2(2mo ago)08BSD-3-ClausePHPPHP >=8.1

Since Dec 27Pushed 2mo agoCompare

[ Source](https://github.com/Illusiard/yii2-entity-acl)[ Packagist](https://packagist.org/packages/illusiard/yii2-entity-acl)[ RSS](/packages/illusiard-yii2-entity-acl/feed)WikiDiscussions master Synced 1mo ago

READMEChangelogDependencies (2)Versions (5)Used By (0)

yii2-entity-acl
===============

[](#yii2-entity-acl)

ACL-система для Yii2 с unix-подобной моделью прав и расширяемыми условиями доступа.

Пакет предназначен для использования совместно с `yii2-base-entity-system`, но не имеет жёсткой зависимости от него и может применяться самостоятельно.

Основная цель — дать **прозрачную, расширяемую и предсказуемую** модель контроля доступа, подходящую для сложных бизнес-сценариев (CRM, SaaS, back-office системы).

---

Основные принципы
-----------------

[](#основные-принципы)

1. **Unix-like модель прав**

    - owner / group / other
    - битовые флаги операций
    - отдельные правила для сущности и для конкретной записи
2. **Allow / Deny conditions**

    - условия могут как запрещать, так и разрешать доступ
    - deny всегда имеет приоритет
    - allow может разрешить доступ даже если базовые права запрещают
3. **Расширяемость**

    - subject (кто) — через `SubjectResolverInterface`
    - when (условия) — через handler’ы условий
    - storage — через `AclStorageInterface`
4. **Детерминированный порядок принятия решений**

    - без неявной магии
    - поведение зафиксировано тестами

---

Операции и флаги
----------------

[](#операции-и-флаги)

Используются следующие битовые флаги операций:

ОперацияФлагlist1read2create4update8delete16Флаги комбинируются через побитовое OR.

---

Таблицы
-------

[](#таблицы)

### `bes_acl_record`

[](#bes_acl_record)

Хранит базовые права доступа.

Используется **одна таблица**:

- для прав на сущность (`record_id IS NULL`)
- для прав на конкретную запись (`record_id = `)

Основные поля:

- `entity`
- `record_id` (NULL = правило для сущности)
- `owner_flags`
- `group_flags`
- `other_flags`
- `owner_id`
- `group_id`
- `priority`

---

### `bes_acl_condition`

[](#bes_acl_condition)

Хранит дополнительные условия доступа.

Основные поля:

- `entity`
- `record_id` (NULL = условие для сущности)
- `effect` (`allow` / `deny`)
- `ops_mask`
- `subject_json`
- `when_json`
- `priority`
- `enabled`

---

Порядок принятия решения
------------------------

[](#порядок-принятия-решения)

Для запроса доступа выполняются шаги:

1. **Определение операции**

    - операция переводится в битовую маску
2. **Базовое правило (`bes_acl_record`)**

    - сначала ищется правило для конкретной записи
    - если нет — правило для сущности
    - определяется сегмент: owner / group / other
    - проверяются флаги
3. **Conditions (`bes_acl_condition`)**

    - выбираются все условия для операции
    - применяются record-level и entity-level условия
    - проверяются `subject` и `when`
    - если сработал deny → доступ запрещён
    - если сработал allow → доступ разрешён
4. **Итог**

    - allow condition
    - иначе base allow
    - иначе deny (по умолчанию)

Deny всегда имеет приоритет над allow и base-правами.

---

Subject (кто)
-------------

[](#subject-кто)

Subject описывает, **к кому применяется условие**.

Пример `subject_json`:

```
{
  "userId": 1,
  "groupId": 10
}
```

Поддерживаемые ключи (по умолчанию):

- `userId`
- `groupId`
- `ownerId`

Разрешение этих значений выполняется через `SubjectResolverInterface`.

### SubjectResolverInterface

[](#subjectresolverinterface)

```
interface SubjectResolverInterface
{
    public function resolveGroupId(int $userId, array $context = []): ?int;
    public function resolveOwnerId(AccessRequest $req): ?int;
}
```

Дефолтная реализация (`ContextSubjectResolver`) читает значения из `AccessRequest->context`.

---

When (когда)
------------

[](#when-когда)

When описывает **условия времени/контекста**, при которых правило применяется.

Пример `when_json`:

```
[
  { "type": "betweenHours", "from": 9, "to": 17 }
]
```

Поддержка условий реализована через handler’ы:

```
interface ConditionHandlerInterface
{
    public function supports(string $type): bool;
    public function evaluate(array $payload, AccessRequest $req, ConditionEngine $engine): bool;
}
```

### Ссылки на другие условия

[](#ссылки-на-другие-условия)

Допускается ссылка на другие conditions:

```
[
  { "condition": [12, 15] }
]
```

Все указанные условия должны выполниться (логика AND).

---

Кеширование
-----------

[](#кеширование)

`DbAclStorage` использует **in-memory кеш** на время запроса:

- ACL записи
- список conditions
- conditions по id

Это позволяет вызывать `can()` много раз без повторных запросов к БД.

---

Использование
-------------

[](#использование)

```
use illusiard\entity_acl\models\dto\AccessRequest;
use illusiard\entity_acl\AclService;

$req = new AccessRequest(
    userId: 1,
    entity: 'post',
    operation: 'read',
    recordId: '10',
    context: [
        'groupId' => 5,
        'ownerId' => 1,
    ]
);

$allowed = AclService::instance()
    ->policy()
    ->can($req);
```

---

Тесты
-----

[](#тесты)

Логика ACL полностью покрыта unit-тестами:

- порядок применения правил
- приоритет deny / allow
- entity-level vs record-level
- subject-resolver
- conditions

Тесты являются **частью спецификации поведения**.

---

Статус
------

[](#статус)

Пакет предоставляет **стабильное ядро ACL**. UI, редакторы правил и визуализация намеренно не входят в состав и должны реализовываться на уровне клиентского кода или других пакетов.

---

Лицензия
--------

[](#лицензия)

BSD 3-Clause

###  Health Score

39

—

LowBetter than 85% of packages

Maintenance91

Actively maintained with recent releases

Popularity4

Limited adoption so far

Community6

Small or concentrated contributor base

Maturity46

Maturing project, gaining track record

 Bus Factor1

Top contributor holds 100% of commits — single point of failure

How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window.

**Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores.

**Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement.

**Maturity (30%)** — Project age, version count, PHP version support, and release stability.

###  Release Activity

Cadence

Every ~20 days

Total

4

Last Release

73d ago

### Community

Maintainers

![](https://www.gravatar.com/avatar/514a2bdbd1dfc61512460d4026da34187fb5e20e69be3ada0a8594b593dd269a?d=identicon)[Illusiard](/maintainers/Illusiard)

---

Top Contributors

[![Illusiard](https://avatars.githubusercontent.com/u/27963611?v=4)](https://github.com/Illusiard "Illusiard (11 commits)")

###  Code Quality

TestsPHPUnit

### Embed Badge

![Health badge](/badges/illusiard-yii2-entity-acl/health.svg)

```
[![Health](https://phpackages.com/badges/illusiard-yii2-entity-acl/health.svg)](https://phpackages.com/packages/illusiard-yii2-entity-acl)
```

###  Alternatives

[rmrevin/yii2-ulogin

Extension for yii2 ulogin integration

1811.9k](/packages/rmrevin-yii2-ulogin)[kakadu-dev/yii2-jwt-auth

Extension provide JWT auth for Yii2

105.8k](/packages/kakadu-dev-yii2-jwt-auth)

PHPackages © 2026

[Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)