1Вход и переключение компаний /companies
Вход в систему управления компанией происходит через защищённую авторизацию по email и паролю. После входа пользователь попадает в «Личный кабинет» — общее пространство, из которого выбирается активная компания для дальнейшей работы. Это не формальность и не косметический экран: у каждой заведённой компании — полностью независимый набор данных, включая типовой месяц (базовую экономику бизнеса), сценарии роста, утверждённые бюджеты и подключённые интеграции с внешними сервисами. Такая архитектура типична для программ для управления бизнесом, которые изначально проектировались с расчётом на мультикомпанийность, а не добавляли её как надстройку поверх однокомпанийной модели.
Переключение между компаниями — одна из ключевых операций для собственника или финансового директора, который курирует несколько направлений: один клик — и весь интерфейс приложения, от дашборда руководителя до плана продаж, перестраивается под цифры выбранной компании. Меню остаётся тем же самым, но данные за ним — совершенно другие. Это удобно на практике: например, финдиректор управляющей компании может начать утро с проверки показателей одного бизнеса, а через минуту переключиться на другой — без повторного входа в систему, без открытия второго браузера или отдельного окна. Именно такой сценарий использования типичен для автоматизации бизнеса на уровне группы компаний или семейного холдинга, где направлений несколько, а управленец — один и тот же человек, которому нужна единая точка входа.
🏢 Все компании
Выберите компанию для входа в личный кабинет
Актив Диджитал
Digital-агентство
28 сотрудников · активна
ПропТех Студия
Недвижимость
14 сотрудников
МедиаДом
Медиа
9 сотрудников · настройка
Экран выбора компании — карточка активной подсвечена, у каждой свой статус.
⚠0.1.1 Изоляция компаний — на уровне кода, не базы данных
Важная деталь архитектуры, о которой стоит знать любому, кто отвечает за безопасность данных при автоматизации управления компанией: политики безопасности (RLS) в Supabase на таблицах с данными компаний проверяют только факт авторизации — то есть «пользователь вообще залогинен в системе», без проверки того, что запрашиваемые строки принадлежат именно его активной компании. Разделение по компаниям в этой реализации целиком держится на прикладном коде — на паттерне, при котором каждый запрос к базе данных вручную дополняется условием по идентификатору компании, взятому из cookie активной сессии. Пока каждый запрос аккуратно проставляет этот фильтр, всё работает штатно и пользователь одной компании физически не видит данных другой.
Но это значит, что защита данных одной компании от другой существует не на уровне базы данных, а в дисциплине кода на каждой отдельной странице приложения — и один пропущенный фильтр в новом запросе технически способен вернуть чужие данные. Для программы для управления бизнесом, которая изначально задумывалась как мультитенантная система управления предприятием, это существенный архитектурный риск: чем больше страниц и функций добавляется в продукт со временем, тем больше точек, где разработчик обязан не забыть про фильтр по компании. Правильное решение на будущее — перенести изоляцию компаний на уровень самой базы данных через полноценные RLS-политики, которые проверяют принадлежность строки компании автоматически, независимо от того, что написано в коде конкретной страницы. До тех пор эту зону стоит держать в фокусе внимания при любом код-ревью новых запросов.
RLS policy · таблица scenarios
| Проверка | Условие | Статус |
|---|---|---|
| Пользователь авторизован | auth.role() = 'authenticated' | есть |
| Строка принадлежит его компании | — проверки нет — | нет |
Фильтр company_id накладывается только в коде страницы, не в базе.
На уровне базы любой авторизованный пользователь технически может прочитать строку любой компании — изоляция держится на прикладном фильтре.