Мобільний застосунок: система ролей ламається під час зростання команди
Перші ролі в мобільному застосунку описуються парою умов: адміністратор бачить усе, решта — лише своє. Поки співробітників десятки, система ролей живе в одному місці й не заважає.
Коли команда зростає й додаються партнерські сценарії, перевірка прав розповзається: частина умов залишається на клієнті, частина — у серверних обробниках, частина дублюється в панелі адміністратора.
Далі з'являється ціна. Розросла логіка доступу перестає бути передбачуваною: екран, закритий в одному місці, виявляється відкритим в іншому, а роль, видана вручну, не відкликається під час переведення співробітника.
Будь-яка правка списку дозволів перетворюється на новий випуск застосунку, і поки він триває, ручна видача прав залишається єдиним способом закрити задачу.
Виручає одна точка ухвалення рішення. Ролі й дозволи живуть на боці сервера, застосунок отримує готовий набір разом із токеном і не зберігає копію в себе — так само влаштований доступ у Keycloak.
Перевірка прав усередині застосунку перетворюється на один виклик, а відкликання спрацьовує одразу, а не після оновлення.
Розбираємо, як це закривається: які ролі виділяти, де відбувається перевірка, як змінювати матрицю доступу без нового випуску і що відбувається з уже виданими дозволами.
Що дає керований доступ: вимірювані ефекти
Права перестають бути частиною екранів і стають окремим сервісом, який на кожен запит відповідає «можна / не можна» і чому. Рішення ухвалюється за матрицею ролей, а не за умовою, розмазаною по модулях інтерфейсу.
Ефекти нижче ми вимірюємо за журналом перевірок: скільки запитів пройшло штатно, скільки відхилено і скільки правил змінювали вручну.
Одна перевірка замість копій правил у кожному модулі
Усі звернення до даних проходять єдину точку перевірки прав, тому правило описане один раз. Частка ручних правок у зверненнях падає з третини до одиниць відсотків: типові сценарії закриває матриця ролей, а вручну налаштовують лише нові ролі, а не розбіжності між екранами.
Разом із копіями логіки зникає цілий клас відмов — коли роль на одному екрані трактується інакше, ніж на іншому, і запит проходить там, де проходити не повинен. Відтворити таку розбіжність більше нема чим: інтерфейс будується з відповіді сервісу прав.
Правка доступу без нового випуску застосунку
Зміна прав — це правка конфігурації, а не коду, тому не потрібні перезбирання й випуск у магазинах застосунків.
Роль видають або відкликають, клієнт бачить результат із першого ж запиту, а повернення до попередньої матриці відновлює попередню поведінку без очікування нової версії.
Швидкість випуску версій зростає рівно на обсяг задач із доступу, які більше не стоять у черзі релізу й не тягнуть за собою повторну перевірку збирання.
Передбачуваність доступу тримається й на межі із зовнішніми системами: шар сумісний із постачальниками облікових записів на кшталт Keycloak, тому зміна такого постачальника не переписує матрицю ролей, а перевірка залишається в одному місці.
Підходи до розмежування ролей: де зберігати права
Розмежування доступу починається з питання, де живе джерело істини про права: від цього залежить, як швидко змінюється доступ після переведення співробітника і що бачить людина без мережі.
Чотири схеми, між якими реально обирають під час проєктування системи ролей, різняться не ідеологією, а ціною помилки.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Права на пристрої | Автономна робота: склад, виїзний сервіс, офлайн-обходи | Зміна прав потребує нового збирання, відкликання доступу в звільненого запізнюється |
| Серверна видача прав | Чутливі дані, часті зміни ролей | Кожен екран чекає відповіді, під час обриву зв'язку доступ зникає |
| Гібридна схема доступу | Потрібні і миттєвий відгук, і керованість | Потрібне правило розв'язання конфліктів локальної та серверної версії |
| Зовнішній постачальник входів | Уже є корпоративний каталог співробітників | Залежність від чужої доступності, власна логіка прав залишається |
Кеш ролей потрібен у будь-якій зі схем. Права складаються в захищене сховище на пристрої разом із версією політики та міткою часу: під час запуску інтерфейс будується за локальною копією, а у фоні вона звіряється із сервером — нові права застосовуються без перезапуску застосунку.
Щоб відкликання доступу не розтягувалося на весь час життя копії, термін кешу тримають коротким, а зверху додають примусову інвалідацію сигналом із сервера. Далі розбираємо, як це влаштовано на рівні маршрутів і перевірок.
Етапи впровадження: від розбору сценаріїв до передачі регламентів
Систему ролей збирають не за інтуїцією: спочатку фіксують, що взагалі можна робити в застосунку, і лише потім вирішують, кому це дозволено. Кожен етап спирається на артефакт попереднього, тому підсумкова схема не розходиться з кодом через місяць після передачі.
-
Інвентаризація дій у застосунку. Проходимо екрани й мережеві виклики, виписуємо кожну дію — від перегляду картки замовлення до зміни тарифу. Результат — таблиця «дія → ресурс → власник»; вона стає єдиним джерелом правди, і дія, що не потрапила до неї, у роль не просочується.
-
Проєктування схеми ролей і успадкування. Ролі збираємо з наборів прав, а не з окремих перемикачів: базовий набір успадковується, дочірня роль додає або відкликає точково. Успадкування тримаємо в один-два рівні — глибше схему неможливо прочитати й перевірити.
-
Налаштування перевірок доступу. Права перевіряються на серверному боці, на клієнті — лише видимість елементів інтерфейсу. Єдиний шар перевірки перехоплює всі вхідні запити, тому новий екран не можна випустити в обхід прав.
-
Перевірка на реальних сценаріях. Тестуємо не ролі окремо, а шляхи користувачів: зміну ролі на активній сесії, відкликання прав, спробу дістатися до чужих даних. Окремо дивимося відмову в доступі — екран має пояснити причину, а не впасти.
-
Передача регламентів. Віддаємо матрицю прав, опис ролей та інструкцію з додавання нової, проводимо навчання команди замовника. Адміністратор далі сам видає й знімає доступи, не звертаючись до розробки.
Що залишається в проєкті: матриця доступу, схеми та регламенти
Після запуску система ролей живе довше, ніж команда, яка її збирала: змінюються співробітники, тарифи, зовнішні партнери. Тому проєкт ми закриваємо не демонстрацією екрана, а набором артефактів, за якими нові інженери й підтримка ухвалюють рішення без нас.
- Матриця «роль — дія» — для кожної дії зазначено, хто її виконує і на які об'єкти вона поширюється. Єдине джерело правди в спірних зверненнях: видно, що обмеження закладене навмисно, а не загубилося під час доопрацювання.
- Опис успадкування ролей — з яких базових ролей збираються складені (наприклад, регіональний керівник = керівник + звіти свого регіону). Правиш базову — розумієш, у кого ще зміняться права.
- Налаштування перевірок — де саме ухвалюється рішення про доступ: на сервері, у застосунку чи в обох місцях, і чому інтерфейс не можна вважати захистом.
- Автотести на доступ — набір перевірок виду «роль X не може виконати дію Y», який проганяється під час кожного збирання. Розширили роль — тест покаже, чи не відкрився зайвий доступ.
- Регламент видачі та відкликання доступу — хто погоджує, за який час права з'являються під час переведення співробітника і закриваються під час звільнення, де залишається слід про зміну.
- Інструкція для служби підтримки — типові звернення («не бачу розділ», «зникли дані») і готові відповіді, щоб не ескалювати кожне на розробку.
Кейс: видача прав перестала бути ручною операцією
Партнерський контур мережі клінік «Гарант-Мед» тримався на ручній видачі доступів: 9 ролей і 60 сценаріїв у застосунку, але права на нові розділи дописували прямо в таблиці «користувач — екран».
Роль для партнерської лабораторії збирали копіюванням сусіднього запису, тому лікар однієї мережі бачив розклад іншої. Звернення до підтримки щодо доступів ішли по 8–10 на тиждень, а будь-яка зміна прав чекала випуску нового збирання.
Що змінили
Ролі описали декларативно — як набір прав на об'єкти й операції, а не на екрани. Перевірку винесли на серверний шар, а в застосунок віддаємо короткий зліпок прав з обмеженим терміном життя: нова видача підхоплюється без оновлення збирання.
Для партнерів завели окрему роль із прив'язкою до організації та виду послуг — її налаштовує адміністратор мережі, не зачіпаючи решти.
Заміри до і після
У цьому кейсі розмежування доступу частка ручних операцій під час видачі впала з 60% до 5%: типові випадки закрилися шаблонами ролей.
Звернення до підтримки скоротилися з 8–10 до 1–2 на тиждень, час випуску змін прав — із двох днів погоджень до півгодини і без нової версії застосунку. Журнал змін ролей залишився обов'язковим: спірні ситуації розбираються за ним за хвилини, а не за листуванням.
Чим відрізняється роль від права доступу?
Роль — це іменований набір дозволів, закріплений за функцією співробітника: комірник, старший зміни, регіональний керівник. Право доступу — атомарна операція над конкретним об'єктом: відкрити заявку, підтвердити виплату, вивантажити список клієнтів.
Розділення принципове: роль відповідає на питання «хто ця людина в процесі», право — «що саме вона може зробити». Коли роль змінюється, достатньо поправити один набір — інтерфейс і перевірки підтягнуть зміни автоматично.
Схема ламається, коли права починають видавати напряму, минаючи роль.
Спершу це виглядає зручною дрібницею для одного співробітника, а за пару релізів у двох менеджерів з однаковою посадою різні набори доступів, ніхто не пам'ятає причину відмінностей, і будь-яка перевірка прав перетворюється на археологію за історією змін.
Складені ролі та успадкування дозволів повертають керованість: базова роль описує спільний мінімум, прикладна — додає галузеві дозволи, а не переписує базу цілком.
Успадкування дає одне джерело істини, але потребує явних правил розв'язання конфліктів — інакше незрозуміло, що переможе, якщо одна роль дозволяє операцію, а інша її забороняє.
Обмеження схеми доступу варто закладати заздалегідь: глибину вкладеності, число ролей на одного користувача й перелік операцій, які не делегуються взагалі.
І перевірка завжди виконується на боці сервісу — у застосунку залишається лише відрисовка інтерфейсу за отриманим набором дозволів.
Роль і право — різні сутності з різним життєвим циклом. Тримайте їх окремо, і схема доступу залишається читабельною: видно, хто що може, чому і як це відкликати.
Технічні сумніви: інтеграції, кеш, офлайн-режим
Права в застосунку живуть у двох місцях: на сервері, де зберігається джерело істини, і в локальному кеші на пристрої — щоб інтерфейс не чекав відповіді мережі.
Розбіжність між ними дає більшість спірних ситуацій: співробітник бачить кнопку, яка йому вже недоступна, або не отримує щойно видане. Нижче — відповіді на те, що інженери й техліди запитують до старту робіт.
Що бачить співробітник, якщо мережа зникла?
Застосунок працює на останньому підтвердженому наборі прав із локального кешу, а операції, що потребують мережі, стають у чергу й виходять під час відновлення зв'язку. Сервер під час приймання все одно переперевіряє права — черга не стає обхідним шляхом.
Як застосунок дізнається про зміну прав, якщо кеш застарів?
У запису короткий термін життя плюс сигнал про зміну ролі: застосунок перезапитує набір прав, не чекаючи на сплив. Якщо сигнал загубився, рятує оновлення під час повернення в застосунок, а критичні дії перевіряються на сервері.
Застосунок працюватиме з нашою наявною системою входів?
Прив'язуємося до вашого каталогу користувачів, а не заводимо другий. Ролі та групи віддає чинна система входів, застосунок тримає поверх неї шар правил «що дозволено на цьому екрані». Дублювання облікових записів і ручної синхронізації не з'являється.
Як швидко закривається доступ у звільненого співробітника?
Відкликання йде від сервера: сесія позначається недійсною, оновлення прав вирушає на пристрій. Поки пристрій офлайн, він працює на старому наборі, але операції, що потребують свіжих прав, сервер до цього моменту не приймає — вікно закривається під час першого виходу в мережу.
Обговоримо задачу: надішліть опис доступу — повернемося з планом
Щоб повернутися з планом робіт щодо ролей, а не із загальними формулюваннями, нам потрібен мінімум ввідних.
Надішліть поточний опис доступу: перелік ролей, матрицю «роль → об'єкт → дія» і те, як права видаються та відкликаються сьогодні — вручну, через адмінку чи синхронізацією з корпоративним каталогом. Цього достатньо, щоб оцінити обсяг робіт і назвати порядок етапів.
Що допомагає прискорити старт проєкту:
- список ролей і груп із розшифровкою, що кожна може робити в застосунку;
- матриця прав у будь-якому вигляді — таблиця, скриншоти екранів, вивантаження з внутрішньої системи;
- як влаштований вхід: логін і пароль, зовнішній провайдер, корпоративний обліковий запис;
- де і як довго живуть сесії, як виконується вихід на всіх пристроях користувача;
- що вже реалізовано: перевірки на екранах, приховування розділів, обмеження на боці сервера;
- вимоги до журналу: чи потрібно фіксувати, хто і коли видав або відкликав право;
- найближчі релізи та терміни, до яких потрібен робочий контур.
На першій розмові розберемо спірні місця: що допустимо вирішувати на клієнті, що обов'язково перевіряти на сервері, як переносити чинних користувачів без блокувань і простоїв.
Опишіть задачу доступу — повернемося з оцінкою обсягу робіт, планом за етапами та критеріями приймання, після чого фіксуємо дату старту.
