Новости и разборы
Кабинет для нескольких компаний: вход не равен доступу к данным
Auth0, Neon и GitLab показывают три слоя изоляции: организация, хранение и проверка каждого действия в приложении.
Сотрудник вошёл в кабинет, но от имени какой компании он сейчас работает? Может ли он открыть чужой заказ по прямой ссылке? При развитии B2B-продукта эти вопросы возникают раньше, чем сложная настройка SSO. Свежие публикации Auth0 и GitLab вместе с сентябрьским разбором Neon помогают отделить три уровня решения.
Компания как отдельный контекст
Auth0 9 октября описал Organizations: участники, подключения к провайдерам входа, метаданные и роли задаются в контексте организации. FlowGrid и Acme в статье прямо обозначены как вымышленные компании. Они объясняют сценарий, но не подтверждают реальный результат внедрения у клиента.
Для собственного кабинета полезно сначала определить принадлежность записей. Один человек может работать с несколькими компаниями и иметь разные права в каждой. Значит, выбранная организация должна сопровождать действие, а не оставаться названием в шапке. Например, возможность читать заказ в одной компании не должна превращаться в право редактировать заказы всех компаний.
Отдельное хранение решает другую задачу
В разборе архитектуры LuBot от 14 сентября Neon описывает отдельную базу на клиента и общий контур аккаунтов и биллинга в Supabase. Это предшествующий материал для сравнения, не октябрьский анонс.
Раздельные базы могут дать явную границу хранения, но приложение всё равно выбирает, к какой базе обращаться. Ошибка этого выбора или чрезмерный доступ администратора не исчезают от самого разделения. Поэтому решение о хранении нужно принимать вместе с требованиями к обслуживанию, восстановлению и управлению клиентскими аккаунтами.
Проверка разрешения нужна после входа
GitLab 5 октября разобрал внутреннее Django-приложение, которое стало обслуживать две аудитории. Проверки login_required оказалось недостаточно для разграничения доступа к модулям. Скрытая ссылка в меню также не заменяет серверную проверку.
Из сопоставления следует практический критерий: система должна знать пользователя, выбранную компанию и разрешение на конкретное действие. Эти сведения затем должны согласованно влиять на выбор данных. Поставщик входа, схема базы и код приложения работают на разных уровнях; ни один слой не подменяет остальные.
Для приёмки подготовьте две тестовые компании и пользователя с разными ролями. Проверьте прямой адрес чужой записи, изменение идентификатора в API, переключение компании и фоновое выполнение уже созданной задачи. Отдельно снимите доступ пользователю и повторите операции. Ожидаемый результат нужно согласовать заранее, включая понятный отказ.
Бизнес-правила и права помогают составить такую проверку. В архивной схеме API описаны модели доступа, а не внедрение этих новых продуктов. При развитии клиентского кабинета обсудите организации, роли и границы данных до добавления следующей интеграции.