Настройка браузерних сповіщень 1С-Бітрікс: інтеграція push

Push-сповіщення в браузері перестають працювати — ми стикаємося з цим щомісяця на десятках проєктів. Налаштування браузерних сповіщень 1С-Бітрікс — задача, яка потребує точної конфігурації VAPID-ключів та Service Worker. Типові сценарії: сервер не віддає публічний ключ, воркер реєструється з невірним scope, або підписка мовчки втрачається при зміні HTTPS-сертифіката. У кожному з цих випадків користувач просто не отримує сповіщення — без помилок на фронті. Ми налаштовуємо push-сповіщення під ключ з гарантією коректного ресабскрайба. За час роботи ми виконали понад 200 проєктів і знаємо всі підводні камені.

Як влаштована підписка в Бітріксі

Модуль 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. Це відбувається коли Бітрікс встановлено в підпапку, або коли в 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 з шляхом до воркера:

location /bitrix/js/push-sender/sw/ { add_header Service-Worker-Allowed '/'; } 

Нехтування цим заголовком призводить до того, що сповіщення не працюють на всіх сторінках, окрім /bitrix/.

Як ми налаштовуємо VAPID-ключі під ключ?

При зміні домену або переміграції сайту старі VAPID-ключі в b_option залишаються, але всі існуючі підписки в b_push_sender_subscription стають невалідними — браузер їх відхиляє з 410 Gone. Бітрікс не очищає таблицю автоматично. Ми перестворюємо ключі та чистимо підписки в рамках одного етапу.

// Генерация новой пары 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([]); 

Після цього всі активні користувачі при наступному візиті автоматично перепідпишуться — браузер отримає новий публічний ключ і створить нову підписку. Такий підхід дає в 3 рази менше відмов порівняно з простою перегенерацією.

Як діагностувати проблеми через логи?

Для налагодження вмикається лог в налаштуваннях модуля push.sender: параметр log_level в b_option. При значенні debug всі запити до push-endpoints пишуться в /bitrix/modules/push.sender/logs/. Типові коди відповідей:

При масових 410 потрібно чистити b_push_sender_subscription через фільтр по даті останньої невдалої відповіді — інакше агент буде холостим ганяти застарілі записи при кожному запуску.

\Bitrix\Main\Config\Option::set('push.sender', 'log_level', 'debug');