Разработка личного кабинета

Способ авторизации выбирается под аудиторию, а не по привычке. Для физических лиц обычно вход по номеру телефона с кодом: паролей никто не помнит, а телефон есть у всех. Для корпоративных клиентов - почта с паролем и двухфакторная аутентификация, потому что за учётной записью стоят деньги и документы.

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

Роль - это не галочка «администратор», а набор правил на трёх уровнях: какие разделы видны, какие действия разрешены и какие именно записи доступны. Третий уровень обычно и забывают: сотрудник филиала не должен видеть заявки соседнего филиала, даже если раздел «Заявки» ему открыт.

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

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

Самая недооценённая деталь - что происходит при неоплате. Доступ отключается сразу или через несколько дней, данные сохраняются или удаляются, можно ли вернуться после паузы. Эти правила определяют логику всего кабинета, и решать их лучше на брифе, чем в первый месяц после запуска.

Кабинет почти никогда не живёт сам по себе: данные приходят из учётной системы, заявки уходят в CRM, документы формируются в бухгалтерии. Через API это соединяется предсказуемо.

Реальные сложности начинаются, когда у системы нет API или он неполный. Поэтому доступ к вашим системам я запрашиваю на первой неделе: выяснить ограничения интеграции в начале проекта дешевле, чем упереться в них за неделю до сдачи.

В кабинете лежат персональные данные, а значит, действуют требования закона: согласие на обработку, политика, хранение на серверах в России, ограничение доступа сотрудников.

Техническая часть - обязательный HTTPS, хеширование паролей, разграничение доступа на уровне запросов к данным, а не только интерфейса, журналирование действий и резервные копии с проверкой восстановлением. Последнее звучит скучно ровно до первого инцидента.