Налаштування браузерних push-сповіщень у 1С-Bitrix
Push-сповіщення в браузері перестають працювати в трьох типових сценаріях: сервер не відправляє VAPID-ключі, воркер реєструється з неправильним scope, або підписка мовчки втрачається при зміні HTTPS-сертифіката. У кожному з цих випадків користувач просто не отримує сповіщення — без помилок на фронтенді.
Як влаштована підписка в Bitrix
Модуль push.sender реалізує Web Push через стандарт VAPID. При першому відвідуванні сайту браузер реєструє Service Worker із файлу /bitrix/js/push-sender/sw/push-worker.js. Цей воркер підписується на push-endpoint браузера (Google FCM, Mozilla Autopush або власний для Safari). Отриманий об'єкт підписки (PushSubscription) зберігається через AJAX-виклик до BX.PushServer.subscribe(), який записує дані в таблицю b_push_sender_subscription.
Серверна частина зберігає VAPID-ключі в параметрах модуля — таблиця b_option, параметри push_server_public_key та push_server_private_key. При відправленні сповіщення використовується метод \Bitrix\PushSender\Model\Subscription::send(), який звертається до класу \Bitrix\Main\Web\HttpClient для POST-запиту до push-endpoint.
Проблема зі scope та шляхом воркера
Найчастіша помилка — Service Worker реєструється з неправильним scope. Це трапляється, коли Bitrix встановлений у піддиректорії, або коли в nginx стоїть нестандартний alias. Воркер із /bitrix/js/... не може керувати сторінками на /shop/, тому що scope за умовчанням дорівнює директорії, з якої завантажений файл воркера.
Рішення — явна передача параметра scope при реєстрації. У файлі /bitrix/js/push-sender/push-sender.js виклик navigator.serviceWorker.register() повинен містити:
navigator.serviceWorker.register('/bitrix/js/push-sender/sw/push-worker.js', {
scope: '/'
});
Якщо файл воркера знаходиться в /bitrix/, а scope потрібен на /, сервер повинен відправляти заголовок Service-Worker-Allowed: / для цього JS-файлу. В nginx це додається через add_header для location зі шляхом до воркера.
VAPID-ключі та їх перестворення
При зміні домену або перемиграції сайту старі VAPID-ключі в b_option залишаються, але всі існуючі підписки в b_push_sender_subscription стають невалідними — браузер їх відхиляє з 410 Gone. Bitrix не очищує таблицю автоматично.
Правильна процедура перестворення ключів:
// Генерація нової пари VAPID
$keys = \Bitrix\PushSender\Security\VapidKey::generateKeyPair();
\Bitrix\Main\Config\Option::set('push.sender', 'push_server_public_key', $keys['publicKey']);
\Bitrix\Main\Config\Option::set('push.sender', 'push_server_private_key', $keys['privateKey']);
// Очистка застарілих підписок
\Bitrix\PushSender\Model\SubscriptionTable::deleteByFilter([]);
Після цього всі активні користувачі при наступному візиті автоматично переподпишуться — браузер отримає новий публічний ключ та створить нову підписку.
Сегментація та відправлення
Модуль підтримує відправлення за користувачами (USER_ID), за сесіями та трансляцію. Для програмної відправлення:
\Bitrix\PushSender\MessageSender::send(
\Bitrix\PushSender\MessageSender::TYPE_PUSH,
[
'USER_ID' => [15, 42],
'MESSAGE' => 'Ваше замовлення відправлено',
'TITLE' => 'Оновлення замовлення',
'URL' => '/personal/orders/123/',
]
);
Метод send() ітерує підписки з b_push_sender_subscription за переданими USER_ID та ставить завдання в чергу агентів — таблиця b_agent, агент \Bitrix\PushSender\Agent\SendMessageAgent.
Діагностика через логи
Для налагодження увімкніть логування в параметрах модуля push.sender: параметр log_level в b_option. При значенні debug усі запити до push-endpoints записуються в /bitrix/modules/push.sender/logs/. Типові коди ответів: 201 — доставлено, 404 — endpoint не існує, 410 — підписка видалена користувачем, 429 — rate limit на боці FCM.
При масових 410 очищуйте b_push_sender_subscription через фільтр за датою останньої невдалої відповіді — іншше агент буде вхолосту гонити застарілі записи при кожному запуску.