Социальные сервисы (socialservices) 25.0.0 от 02.09.2025

Последний коммит принёс обновление модуля socialservices, отвечающего за интеграцию с внешними сервисами авторизации. Версия поднялась до 25.0.0. На первый взгляд, изменения минорные, но в них есть как минимум одно важное улучшение и один потенциальный "breaking change", который стоит иметь в виду.

1. Ключевое изменение: принудительное обновление токенов Google

В классе CSocServGoogleProxyOAuth была значительно переработана логика сохранения токена авторизации.

Что изменилось: Теперь перед добавлением или обновлением токена пользователя система принудительно удаляет все его старые токены для данного сервиса (Google). За это отвечает новый приватный метод deleteOldTokens.

Было (упрощенно):

        // bitrix/modules/socialservices/classes/general/googleproxy.php
// ...
$socservUser = UserTable::getList([...])->fetch();

if(!$socservUser) {
    UserTable::add($fields);
} else {
    UserTable::update($socservUser['ID'], $fields);
}

    

Старый код просто обновлял существующую запись или добавлял новую. Если по какой-то причине для пользователя существовало несколько записей (например, из-за сбоев), могли возникать коллизии.

Стало:

        // bitrix/modules/socialservices/classes/general/googleproxy.php
// ...
if (!empty($socservUserFields['USER_ID'])) {
    $this->deleteOldTokens($socservUserFields['USER_ID'], $socservUserFields['EXTERNAL_AUTH_ID']);
    // ... дальнейшая логика добавления/обновления ...
}

    

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

Зачем это нужно? Это повышает надёжность и предсказуемость механизма авторизации. Исключается ситуация, когда в базе "зависают" старые, неактуальные токены, которые могут быть ошибочно использованы системой. По сути, это исправление потенциальной, хоть и редкой, проблемы.

2. Архитектурный рефакторинг: работа с часовым поясом

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

Что произошло на самом деле?

1. Удалён старый механизм (явное изменение)

Из класса CSocServAuth исчез вот этот блок:

        // bitrix/modules/socialservices/classes/general/authmanager.php
if(isset($socservUserFields["TIME_ZONE_OFFSET"]) && $socservUserFields["TIME_ZONE_OFFSET"] !== null)
{
    CTimeZone::SetCookieValue($socservUserFields["TIME_ZONE_OFFSET"]);
}

    

Что он делал? Он брал из данных соцсети числовое смещение от UTC (например, 10800) и вручную устанавливал cookie для пользователя. Этот подход имел два недостатка:

• Неточность: Смещение не учитывает переход на летнее/зимнее время.
• "Костыль": Модуль socialservices выполнял работу, которую должно делать ядро.

2. Включился новый механизм (неявное изменение)

Теперь модуль socialservices просто передает массив данных пользователя ($socservUserFields) в стандартные методы ядра CUser::Add или CUser::Update. Внутри этих методов (в модуле main) заложена логика обработки стандартного поля пользователя TIME_ZONE.

Если в массиве $socservUserFields присутствует ключ TIME_ZONE с идентификатором (например, Europe/Moscow), ядро Битрикса автоматически:

• Сохранит этот идентификатор в профиле пользователя.
• Корректно установит часовой пояс в сессии пользователя.

Это видно в коде CUser::Update (/bitrix/modules/main/classes/general/user.php, ~4089 строка), который обновляет параметры сессии:

        if (is_object($USER) && $USER->GetID() == $ID) {
    static $arSessFields = [
        //...
        'TIME_ZONE' => 'TIME_ZONE', // <-- Ядро знает про это поле
    ];
    foreach ($arSessFields as $key => $val) {
        if (isset($arFields[$val])) {
            $USER->SetParam($key, $arFields[$val]); // <-- И само обновляет сессию
        }
    }
}

    

3. Интересные находки

• Отказ от "костылей" в пользу ядра: Рефакторинг работы с часовым поясом — это отличный пример того, как модуль избавляется от частного решения и переходит на использование стандартных API платформы. Это делает систему в целом более стабильной и предсказуемой.
• Чистота и порядок: Внедрение метода deleteOldTokens для очистки старых токенов Google — это хороший рефакторинг, который изолирует одну конкретную задачу и делает код более читаемым.