Что нужно знать об интеграции вебпушей
Пошаговую инструкцию по интеграции можно найти по ссылке.
В данной статье подробно рассмотрим её важнейшие составляющие и зачем они нужны.
SERVICE WORKER (SW)
Что это такое?
SW - это скрипт, работающий в фоновом режиме браузера. Он позволяет обрабатывать данные и делать запросы, даже если клиент покинул сайт.
Проще говоря: поддерживает работу офлайн - можно отправлять пуши и тем, кто сейчас не пользуется браузером. Пользователь получит пуш при следующем запуске браузера.
Как SW участвует в процессах вебпушей?
- Подписка и обновление данных клиента:
SW передаёт данные в mindbox о разрешении/запрете на показ пушей в браузере, а также токен при наличии разрешения.
- Отправка пушей:
SW получает сообщение от firebase о наличии пуша для браузера клиента и отрисовывает его.
Поэтому доступность пушей напрямую зависит от поддержки браузером SW. На данный момент положение следующее: пуши полностью поддерживаются на десктопе в последних версиях Chrome, Яндекс.Браузер, Opera, Firefox, Edge и на мобильных устройствах в Chrome и Firefox.
На iOs вебпуши не поддерживаются.
Следить можно по ссылке.
- Взаимодействие с пушом:
SW регистрирует клик по пушу и передаёт эту информацию в mindbox.
Какую роль играют расположение SW и его scope?
Scope - это область видимости SW. Он определяет, из какой части домена SW принимает запросы.
Scope указывается относительно корня домена, а не расположения JS-файла, регистрирующего SW. Если файл находится в корне, областью видимости SW является весь сайт.
Указывать его не обязательно. В таком случае область видимости будет соответствовать расположению файла SW.
Например, у вас есть сайт example.com и на нём установлен SW со значением scope /new/
В таком случае область видимости SW включает директории /new/, /new/one/, /new/one/more/, но не /new и / .
То есть со страницы example.com SW принимать запросы не будет.
Область видимости не может быть выше расположения SW.
Чтобы обойти это ограничение, область видимости можно расширить с помощью заголовка Service-Worker-Allowed.
Например, SW расположен по адресу https://example.com/one/two/three/, а мы хотим увеличить его область видимости до https://example.com/one
Для этого в заголовке Service-Worker-Allowed пропишем ‘/one/’
Почему сайт должен быть HTTPS?
Такое ограничение связано с применением SW и нужно для обеспечения сохранности передаваемых данных.
Дело в том, что, используя SW, можно перехватывать запросы, фильтровать и подменять ответы. Работа по https (HyperText Transfer Protocol) позволяет этого избежать за счёт использования протокола TLS для шифрования данных.
Sender ID
Что это такое?
Для отправки пушей мы пользуемся сервисом Firebase Cloud Messaging (FCM).
На подготовительной стадии мы создаём в нём проект для вашей точки интеграции (ТИ), по сути — сайта.
При этом получаем Sender id (идентификатор проекта в FCM) и секретный ключ.
Как участвует в процессах вебпушей?
- Подписка:
Когда пользователь разрешает показ пушей, в FCM создаётся токен для браузера клиента на этом сайте.
Sender id нужен для того, чтобы токен был добавлен в нужный проект FCM.
- Отправка:
Sender id используется при отправке пуша для нахождения нужного проекта в FCM.
Трекер
При инициализации трекера происходит конфигурирование параметров SW и FCM, необходимых для корректной работы пушей.
mindbox("webpush.create")
Функция запускает инициализацию SW.
Инициирует передачу разрешения и обновление токена посредством SW.
mindbox("webpush.subscribe")
Функция проверяет наличие подписки и разрешения у клиента, запускает показ попапа подписки и создаёт клиента с подпиской и разрешением в случае согласия клиента.
И также инициирует передачу разрешения и обновление токена посредством SW.
mindbox("webpush.migrate")
Для миграции с другого рассыльщика при использовании сбора подписчиков с помощью попапа.
Если клиент ранее давал разрешение на показ пушей, мы не показываем ему попап. Функция создает такого клиента на проекте с подпиской и разрешением.