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