Організації та ролі
Ця сторінка допоможе вирішити, кому яку роль дати і яка область дії потрібна API-ключу. Тут працюють два механізми: орендність визначає, які дані для того, хто звертається, взагалі існують, а ролі — що він може з ними робити.
Організації та проєкти
Section titled “Організації та проєкти”| Термін | Що це |
|---|---|
| Організація | Орендар. Усе, чим володіє клієнт, належить рівно одній організації. |
| Проєкт | Частина роботи організації. Ендпоінти, джерела та API-ключі належать проєкту. |
Межа безпеки — організація. Проєкт нею не є: він упорядковує роботу, але не обмежує, хто її бачить.
Записів іншої організації не існує
Section titled “Записів іншої організації не існує”Кожен запит, який виконує API, обмежується організацією того, хто звертається, на рівні самого шару даних, пошук за ідентифікатором теж. Нікому не треба пам’ятати про фільтр. З цього випливає:
- Запит до ресурсу іншої організації за його ідентифікатором відповідає
404, а не403. Чужий орендар і неправильний ідентифікатор виглядають однаково, тож ідентифікатор нічого не розкриває. - Нова функція API автоматично успадковує це обмеження.
Людина може належати до кількох організацій. POST /api/v1/auth/switch-organization видає токен доступу для іншої її організації з роллю з того членства.
Ролі для людей
Section titled “Ролі для людей”| Роль | Може |
|---|---|
OWNER |
Усе, зокрема налаштування організації, учасників, експорт даних і видалення організації |
DEVELOPER |
Читати й змінювати конфігурацію: ендпоінти, підписки, джерела, правила та решту проєкту |
VIEWER |
Лише читати |
У списку ролей є й четверте значення, API_KEY, але цю роль нікому не призначають. Вона позначає запит, зроблений API-ключем.
Що може лише власник
Section titled “Що може лише власник”- Змінювати налаштування організації.
- Експортувати дані організації та видаляти її. Див. Зберігання та експорт даних.
- Додавати учасників, змінювати їхні ролі, видаляти, призупиняти й відновлювати учасників.
Кілька запобіжників не дають організації замкнути саму себе. Кожен відповідає 409 Conflict:
- Останнього власника, який ще може увійти, не можна понизити, видалити чи призупинити.
- Не можна призупинити самого себе.
- Роль
OWNERне можна надати через запит на зміну ролі.
Області дії для API-ключів
Section titled “Області дії для API-ключів”| Область дії | Дозволяє |
|---|---|
READ_WRITE |
Читання й запис, зокрема надсилання подій |
READ_ONLY |
Лише читання |
API-ключ ніколи не має OWNER, хоч би якою була його область дії. Дії лише для власника завжди потребують людини, яка увійшла як власник.
Як перевіряється запит
Section titled “Як перевіряється запит”Ролі й області дії — різні види дозволів, тож кожна дія API вказує, що їй потрібно від того, хто звертається, а не мінімальну роль:
| Дії потрібно | Пропускає | Відмовляє |
|---|---|---|
| Читання | Будь-кого автентифікованого | — |
| Запис | Власників, розробників, ключі READ_WRITE |
Глядачів, ключі READ_ONLY |
| Власник | Власників | Усіх інших, зокрема будь-який API-ключ |
Відхилений запит відповідає 403 зі стандартним конвертом помилки. Див. Помилки та ліміти.
Чого поки немає
Section titled “Чого поки немає”- Немає власних ролей і дозволів на окремі ресурси. Три фіксовані ролі й дві області дії ключів. Не можна дати комусь запис в одному проєкті й читання в іншому в межах однієї організації.
- Немає SSO (SAML чи OIDC) і немає SCIM.
- Проєкти не є межею дозволів. Кожен учасник бачить кожен проєкт організації з тією самою роллю.