Перейти к основному содержанию

Справочник

Кто к чему имеет доступ: пользователи и права в приложении управления

Приложение управления почти всегда начинается с одного человека. Вопрос доступов встаёт в тот день, когда появляется второй — а стандартный ответ «поделимся паролем» обходится дороже, чем кажется. Вот что именно включает приложение, сгенерированное Blueprint Maker, в части управления доступом, и четыре вещи, которые оно не делает.

«Поделимся паролем»

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

Три механических последствия. Чтобы отозвать доступ у одного человека, придётся сменить пароль у ВСЕХ — и заново инструктировать всю команду в день увольнения, то есть в тот самый день, когда этим заниматься меньше всего хочется. Далее никто не сможет ответить на вопрос «кто изменил эту строку?», ведь для приложения все — один и тот же пользователь. И наконец, нельзя выдать частичный доступ: человек, который просто просматривает цифру, получает те же полномочия, что и тот, кто выставляет счёт.

Речь здесь не о безопасности в драматическом смысле — никто не будет атаковать приложение для пятнадцати человек. Речь о необратимости: общий аккаунт нельзя распутать — его можно только заменить, и чем дольше вы ждёте, тем сложнее эта замена.

  • Отзыв доступа у одного человека = смена пароля у всех.
  • Невозможно ответить на вопрос «кто это сделал?»: один аккаунт — одна личность.
  • Нет режима «только для чтения»: просмотр и редактирование дают одни и те же права.

Три роли и чёткая граница между ними

Как только приложение требует входа в систему, оно сразу предоставляет настоящие отдельные учётные записи и три роли. Их немного — и так задумано: система прав, которую нельзя понять с первого взгляда, почти наверняка будет настроена неверно.

Администратор может делать всё и единственный управляет аккаунтами: создаёт их, деактивирует, сбрасывает пароли. Пользователь работает внутри приложения — создаёт, изменяет и удаляет данные — но не видит раздел управления аккаунтами. Роль «только для чтения» предназначена для просмотра: такой пользователь свободно перемещается по интерфейсу, открывает карточки, читает дашборды, но ничего не может записывать.

Важно не сам список ролей, а то, где именно происходит отказ. Для роли «только для чтения» блокировка — это не скрытая кнопка на экране: любой запрос на запись отклоняется ещё до попадания в маршрут — промежуточным ПО (middleware) с кодом ответа 403. Скрытую кнопку можно обойти с клавиатуры или через инструменты разработчика; отказ, реализованный на уровне middleware, обойти невозможно. Это разница между интерфейсом, который лишь намекает, и приложением, которое действительно обеспечивает контроль.

Роль передаётся в подписанных cookie сессии, поэтому проверка выполняется без обращения к базе данных при каждом запросе. А гость без активной сессии никуда не пройдёт: страницы перенаправят его на экран входа, запомнив, куда он шёл, а API-вызовы вернут код 401.

  • Администратор — полный доступ плюс управление аккаунтами.
  • Пользователь — создаёт, изменяет и удаляет данные; доступ к управлению аккаунтами отсутствует.
  • Только для чтения — просматривает и читает; любая попытка записи отклоняется с кодом 403 до попадания в маршрут.
  • Без сессии — код 401 в API, перенаправление на страницу входа в интерфейсе.

Открытие доступа: идентификатор, роль и временный пароль

Для создания аккаунта требуется три параметра — и ни один из них не является адресом электронной почты. Администратор вводит логин (от 2 до 31 символа: буквы, цифры, точка, дефис, подчёркивание), выбирает роль, а приложение само генерирует временный пароль.

Этот пароль показывается только один раз — в момент создания. После этого его нельзя восстановить ни в списке аккаунтов, ни где-либо ещё: сохраняется лишь его хеш. Если пароль потеряли до того, как успели передать, администратор за десять секунд сгенерирует новый. Кроме того, аккаунт помечается как требующий смены пароля: при первом входе пользователь обязан задать свой собственный пароль, поэтому администратор никогда не узнает пароли коллег.

Никакие письма не отправляются — об этом важно знать заранее: в приложении нет встроенного сервиса электронной почты. Передачу логина и временного пароля берёт на себя администратор — своими средствами. На практике следствие этого оказывается даже более неудобным, чем отсутствие email: функции «забыли пароль?» в автономном режиме нет — если пароль утерян, восстановление проходит через администратора, который его сбрасывает.

Первый аккаунт создаётся вместе с приложением: логин «admin», пароль «admin», и обязательная смена пароля при первом входе. Это стартовый пароль, а не постоянный — и приложение не позволит его оставить.

  • Логин + роль — всё, что вводит администратор.
  • Временный пароль генерируется приложением и показывается ОДИН раз.
  • Обязательная смена пароля при первом входе — после этого администратор его не знает.
  • Нет email: передача и сброс пароля осуществляются через администратора.

Отзыв доступа без пробивания дыры в истории

Аккаунт не удаляется — он деактивируется и может быть вновь активирован. Это не техническое упрощение, а та же логика, что и корзина для данных: окончательно удалённая запись уносит с собой всё, что к ней привязано, и вы замечаете это спустя месяцы — когда ищете то, чего уже нет.

В коде реализованы два явных отказа — именно они не дают случайно заблокировать себя. Нельзя деактивировать собственный аккаунт — это самое простое действие, которое легко совершить по ошибке при очистке списка. И нельзя деактивировать последнего активного администратора: приложение без администратора — это приложение, в котором никто больше не сможет открыть доступ, в том числе себе. Отказ оформлен чётко и не сводится к простому сбою.

Увольнение решается одним действием: без смены паролей у других и без потери следов. Замена требует двух шагов: сначала деактивация, затем создание нового аккаунта.

  • Обратимая деактивация вместо удаления.
  • Нельзя деактивировать собственный аккаунт.
  • Нельзя деактивировать последнего активного администратора.
  • Сброс пароля администратором в любой момент.

Чего это не делает — и лучше узнать об этом заранее

Права доступа глобальны для всего приложения. У каждого аккаунта есть роль, но она не привязана ни к конкретной сущности, ни к разделу, ни к полю. Поэтому невозможно выразить такие условия, как «этот менеджер видит только своих клиентов», «этот сотрудник имеет доступ к заявкам, но не к выставлению счётов» или «это поле скрыто от неуправленцев». Три роли хорошо покрывают вопрос «просмотр или редактирование», но совсем не затрагивают вопрос «какая часть».

Приложение фиксирует ТОЛЬКО КОГДА изменились данные, но НИКОГДА — КТО их изменил. Каждая запись автоматически содержит дату создания и дату последнего изменения, но никакое поле не хранит имя автора. Отдельные аккаунты отвечают на вопрос «кто может войти», но не на вопрос «кто написал эту строку» — это два разных вопроса, и решается только первый. Именно это ограничение чаще всего путают со встроенной возможностью: наличие именованных аккаунтов создаёт иллюзию аудита.

Вход осуществляется только по логину и паролю — и ничем больше. Нет входа через Google или Microsoft, нет корпоративного единого входа (SSO), нет двухфакторной аутентификации. Для команды, которая уже управляет учётными записями в другом месте, это означает ещё один список аккаунтов, за которым нужно следить.

Эти четыре ограничения — не упущения, которые нужно обходить: они очерчивают границы того, что поставляется «из коробки». Гораздо полезнее чётко их зафиксировать, чем оставлять вам открывать их самостоятельно. У всех них есть единое решение — и оно составляет суть продукта: код приложения принадлежит вам. Это стандартный проект на Next.js и Prisma, который можно экспортировать в ZIP или загрузить в ваш собственный репозиторий. Добавить поле «автор», реализовать разделение по отделам или внедрить корпоративную аутентификацию — обычные задачи разработки, выполняемые над кодом, который вы полностью контролируете, и ни один поставщик не может вам в этом отказать. А если разделение по зонам ответственности принципиально для вашего бизнеса — опишите его с самого начала: именно ваш текст определяет сущности и связи между ними.

  • Глобальные права: нет разделения по сущностям, разделам или полям.
  • Фиксируется дата изменения, но не фиксируется автор.
  • Только логин и пароль: нет SSO, сторонних провайдеров входа и двухфакторной аутентификации.
  • Единое решение: код принадлежит вам, а такие доработки — обычная разработка.

Читать далее

Опишите свою организацию — получите приложение, которое её поддерживает