Разработка модуля личного кабинета 1С-Битрикс

Разработка модуля личного кабинета 1С-Битрикс

В Битрикс есть готовый компонент system.auth.registration и страницы личного кабинета в поставке, но их хватает только для простейшего случая: изменить имя и посмотреть заказы. Как только появляется задача «показать бонусные баллы, историю начислений, привязанные карты лояльности, несколько адресов доставки с картой и документы по B2B-договору» — стандартный кабинет становится отправной точкой для переработки, а не готовым решением.

Что отличает полноценный личный кабинет

Базовый кабинет в Битрикс — набор разрозненных компонентов, каждый из которых обращается к БД самостоятельно, без общего слоя данных. В результате страница профиля может делать 15–20 SQL-запросов при загрузке. Модуль личного кабинета строится иначе: один агрегирующий сервис собирает данные пользователя при входе, кеширует их в сессии и отдаёт всем компонентам из единого источника.

Архитектура: слои кабинета

Профильный сервис (UserProfileService) — центральный класс, инкапсулирующий всю логику работы с данными пользователя:

class UserProfileService {
    private int $userId;
    private array $cache = [];

    public function getOrders(array $filter = [], int $page = 1): OrderCollection {
        return \Bitrix\Sale\OrderTable::getList([
            'filter' => array_merge(['=USER_ID' => $this->userId], $filter),
            'order'  => ['DATE_INSERT' => 'DESC'],
            'limit'  => 10,
            'offset' => ($page - 1) * 10,
        ]);
    }

    public function getLoyaltyBalance(): int {
        if (!isset($this->cache['loyalty'])) {
            $this->cache['loyalty'] = LoyaltyTable::getBalanceForUser($this->userId);
        }
        return $this->cache['loyalty'];
    }
}

Компоненты кабинета получают сервис через DI-контейнер Bitrix\Main\DI\ServiceLocator. Каждый компонент отвечает за одну секцию: заказы, адреса, настройки уведомлений, документы.

Роутинг. Для каждой секции — отдельный URL (/cabinet/orders/, /cabinet/addresses/, /cabinet/documents/). Реализуется через кастомный обработчик в urlrewrite.php или через модуль main с регистрацией правил через UrlRewriter::setRule.

Детально: управление адресами доставки

Штатно Битрикс хранит один адрес в профиле пользователя. Для нескольких адресов нужна собственная таблица:

CREATE TABLE myvendor_user_address (
    id          SERIAL PRIMARY KEY,
    user_id     INT NOT NULL,
    label       VARCHAR(100),           -- "Дом", "Работа"
    city        VARCHAR(100),
    street      VARCHAR(200),
    building    VARCHAR(20),
    apartment   VARCHAR(20),
    lat         DECIMAL(10, 7),
    lng         DECIMAL(10, 7),
    is_default  BOOLEAN DEFAULT false,
    created_at  TIMESTAMP DEFAULT NOW()
);

Поля lat / lng заполняются через Яндекс.Геокодер при сохранении адреса. При оформлении заказа пользователь выбирает адрес из списка — данные подставляются в b_sale_order_props без ручного ввода.

Секция документов для B2B

B2B-пользователи часто запрашивают счета, акты, УПД. Модуль связывает документы (генерируемые модулем печатных форм) с профилем пользователя через таблицу myvendor_user_document. В кабинете — фильтрация по типу документа, периоду, статусу, кнопка скачивания PDF. Права на просмотр документов проверяются через группы пользователей.

Уведомления

Пользователь управляет подписками на уведомления: email, SMS, push. Каждый канал — отдельная запись в myvendor_notification_pref. При отправке уведомления из бизнес-логики приложение сначала проверяет предпочтения пользователя, и только потом выбирает канал доставки.

Безопасность кабинета

• Все операции изменения данных (смена email, пароля, адреса) требуют подтверждения через код на email/SMS
• CSRF-защита через стандартный механизм Битрикс (bitrix_sessid)
• Rate limiting на попытки смены пароля через таблицу myvendor_rate_limit
• Маскирование телефона в отображении (показывать только последние 4 цифры)

Сроки разработки

Важно зафиксировать список секций кабинета до старта разработки — добавление новой крупной секции (например, программы лояльности) в середине проекта требует пересмотра профильного сервиса и схемы данных.