Comments 66
У меня сомнения что всё это не работает, потому что в случае с OneSignal это как-то отрабатывает. Банально ставишь плагин уведомлений к Wordpress, жмёшь «Send test notification» и оно приходит.
Как гипотеза, js api от firebase выдает не тот токен (он может и клиентский, да не тот).
Уведомления не доходили потому что нужно было еще прописать messaging.onMessage().
Сейчас все поправил и сделал полноценное приложение с отправкой уведомлений через js
FireBase принимает уведомления, рапортует что всё ок, устройства онлайн, но пуши не доходят. По нашему опыту до 40-45% пушей где-то в недрах оного зависает...
вы не думайте, я не против прогресса. но ситуация как с рекламой — когда ею начали злоупотреблять, то нашлись всеми рекламодателями нелюбимые контрмеры. я бы даже как-нибудь сел, да и запилил пост-фидбек по всему этому новому лицу интернета, что раньше было удобнее, а что сейчас.
Ещё, кажется, так они(Гугл, в основном) стараются разрабов Apple(см. iOS, Service Workers) подтолкнуть внедрить push у себя в браузере и чему я рад, так как не хватает сильно в работе, связанной с темой умных домов.
Полагаю, что часто это выглядит так. Заказчик, далекий от IT открывает для себя PUSH и сразу озвучивает свою хотелку. На все уверения о том что многих будет бесить, что нужно запрашивать разрешение только по клику отвечает: "Хочу чтобы работало сразу при заходе на сайт".
Подскажите, пожалуйста, каким образом можно кастомизировать окно с предложением подписаться? Видел на нескольких сайтах нестандартные диалоги подписки, но беглый гуглинг ответа не дал.
Видел и задавался тем же вопросом. В документации не описаны какие либо методы по кастомизации окна. Подозреваю что это делается через какие-то костыли и хуки. Не советую вам это делать. Единообразие интерфейса не есть плохо
2. Если использовать push api напрямую, то VAPID и надо шифровать payload.
3. >не самая дешевая операция
Да, если делать это (multi)curl'ом на похопе (~250 пушей в минуту). На golang с concurency=200 (столько хочет гугловый http2) получается ~1000 пушей в секунду.
4. Стандарт до сих пор не утвержден. И лучше не изобретать свой велосипед, а использовать один из кучи готовых сервисов, которые и о передрягах стандарта позаботятся и поддержку iOS/Safari обеспечат.
3. не самая дешевая операция
Да, если делать это (multi)curl'ом на похопе (~250 пушей в минуту). На golang с concurency=200 (столько хочет гугловый http2) получается ~1000 пушей в секунду.
окей. А теперь представим что у вас 5000 подписчиков. Это значит что страница у вас будет открываться на 5 секунд дольше обычного и пользователи будут отказываться от вашего ресурса из-за ожидания, не смотря на то что вы используете супер продвинутый Go. Поставить же событие в очередь займет милисикунды, а разбирать очередь можете на чем угодно в фоне, хоть на PHP, хоть на Go, хоть на C.
4. Стандарт до сих пор не утвержден. И лучше не изобретать свой велосипед, а использовать один из кучи готовых сервисов, которые и о передрягах стандарта позаботятся и поддержку iOS/Safari обеспечат.
А кто изобретает велосипед? Как раз напротив. Я пытаюсь показать как реализовать уведомления используя стандартные средства (в данном случае средствами представленными Google), не прибегая к сторонним сервисам. Сторонние сервисы плохи тем что:
- они получают полный доступ к нашему контенту который может содержать конфеденциальную информацию;
- они встраивают рекламу в уведомления и им нужно отдельно платить за то, чтоб они этого не делали;
- большинство имеют ограничение на количество подписчиков и уведомлений. После выхода за лимит начинают требовать деньги;
- сторонние сервисы вообще живут за счет того, что просят деньги за свои услуги.
Внимание вопрос. Зачем платить за то что можно сделать бесплатно? Причем абсолютно легально и стандартизировано.
Я не хочу сказать, что сторонние сервисы это зло. В своем личном, некоммерческом проекте я скорей всего воспользуюсь их услугами. А вот серьезные организации, которым важен престиж и конфиденциальность, такой вариант не рассматривают.
PS: я уже обсуждал тему осмысленности сторонних сервисов для отправки push-уведомлений с автором проекта PushAll BupycNet и не хотел бы возвращаться к этой теме.
2. firebase api — это не стандартное средство. Стандартное — webpush api. Гугл его целиком и полностью поддерживает.
1. Заметь, я же нигде не говорил, что очередь не нужна. Но даже в фоне разбирать события курлом — плохой вариант.
Надо было так и говорит. "Не используйте cURL." Я вас неправильно понял.
2. firebase api — это не стандартное средство. Стандартное — webpush api.
Хорошо. Назовем это так — Библиотека/обертка над нативным интерфейсом. Что в этом плохого?
Согласен, лучше это решать нативными средствами.
Может вы поделитесь с обществом своим опытом в этой сфере?
2. У Мозиллы есть несколько довольно подробных и понятных заметок с примерами, они работают и для хрома (с добавлением FCM-ключа и манифеста) https://developer.mozilla.org/en/docs/Web/API/Push_API#See_also
Для хрома стоит прочесть https://developers.google.com/web/updates/2015/03/push-notifications-on-the-open-web (не смотря на пометку об устаревании) и минимально-рабочий пример https://github.com/chrisdavidmills/push-api-demo
1. Заметь, я же нигде не говорил, что очередь не нужна. Но даже в фоне разбирать события курлом — плохой вариант.
Раз пошла такая тема. Нужно определится на чем написан сайт и бизнес логика проекта. Бизнес логика это самое важное в проекте и она определяет как отреагировать на то или иное событие.
Если проект написан на Go, то логично и уведомления отправлять через Go.
Если проект написан на PHP (как это часто бывает), то можно завести вторую очередь. Первая хранит события, а вторая уже готовые уведомления которые нужно отправить. А вот в качестве транспорта для отправки уведомлений из второй очереди, можно в этом случае использовать микросервисы на Go.
В этом случае мы можем потерять в производительности из-за 2 очередей, но зато логика будет прозрачной.
Если использовать Firebase Cloud Messaging, то очередь не нужна: https://firebase.google.com/docs/cloud-messaging/js/send-multiple.
Стандарт до сих пор не утвержден. И лучше не изобретать свой велосипед, а использовать один из кучи готовых сервисов, которые и о передрягах стандарта позаботятся и поддержку iOS/Safari обеспечат.
Да, спецификация W3C Push API не утверждена в том смысле, что ещё пока не достигла статуса рекомендации W3C, но её уже можно активно использовать. Куда более важна поддержка спецификации различными браузерами: http://caniuse.com/#feat=push-api. Более детальные сведения: https://github.com/web-push-libs/web-push#browser-support. Хотя эти сведения тоже неполные — нет деления на платформы, что важно, так как, например, на iOS все браузеры вынуждены использовать движок WebKit со всеми вытекающими из этого последствиями в виде поддержки спецификаций.
Многие спецификации, например Service Workers и Web Components до сих пор не получили статус рекомендации W3C, но это не повод их не использовать.
Честно говоря больше интересует, как можно реализовать свой собственный сервер уведомлений, а не использовать сторонние.
Длинный ответ: ServiceWorker+ Fetch/Streams. И свой костыль для fingerprinting'а клиента, подписки, отписки и всего вот этого. Сделать свой, совместимый с WebPush API сервер не представляется возможным, поскольку их адреса вшиты в коде браузеров и не доступны к изменению из js.
А так, мне в целом стандарт странным кажется. Несмотря на наличие firebase и мозилловскиго сервера нужен все равно свой для рассылки. Куда логичней были бы каналы подписки и апи для отравки сообщения сразу всем подписанным клиентам, поскольку задача «отправить одно сообщение сразу всем» возникает гораздо чаще, нежели «отправить кому-то конкретному».
Все тут правильно, Вы не задумывались как будете слать уведомления со своего сервера браузеру? Ответ весьма прост никак. Первой преградой будет динамический ip, а второй и непреодолимой это НАТ. Ну да ладно живем-то во времена НАТа, пускай браузер сам подключаться к 100500 сайтам, на которые подписан пользователь. В результате что мы имеем? 100500 бессмысленных постоянных соединений с сайтами на клиенте и то же самое на другом конце провода. Как результат бессмысленная трата ресурсов. В данном случае единый/е сервера к которым подключаются браузер имея 1 соединение и сайты которые ему шлют свои уведомления. Речь идет, разумеется, об уведомления при закрытом сайте/браузере, так как при открытой вкладке с браузером можно использовать WebSocket, что в данном случае оправдано (когда человек на сайте).
За последнее время мы так привыкли ко всем этим API, что забываем как это работает на низком уровне, а ведь ничего особо не изменилось.
P.S. Я надеюсь я правильно Вас понял.
Ну как сказать не автоматизируется. Уведомления это как email сообщения. Они работают через сторонние сервисы. Вопрос осмысленности такого тестирования я не поднимаю.
Некоторые тестируют отправляемые и доставляемые email сообщения поднимая тестовый SMTP сервер. Так и тут. Никто не мешает, при желании, поднять тестовый Service Worker и тестировать уведомления через него.
Тестировать работу самого Service Worker-а уже сложнее так как он работает вне контекста текущей страницы.
Так что статью надо было назвать «Web PUSH Notifications быстро и просто, но очень дорого!», а потом показать что существуют действительно полностью бесплатные решения.
push-уведомления через Firebase бесплатные. Не знаю с чего вы взяли что за них нужно платить. Если использовать сторонние сервисы для отправки уведомлений такие как OneSignal и PushAll, то естественно это будет стоит денег, о чем я писал в одном из комментариев.
CDN естественно стоит денег. Если вы разместите статику на своих серверах, то это уже будет не CDN, а если вы начнете строить свою сеть CDN, то это выйдет дороже для большинства проектов.
На официальном сайте Firebase, в разделе цены, вполне четко описано какие услуги платные, а какие нет
Included Free
Analytics, App Indexing, Authentication, Cloud Messaging, Crash Reporting, Dynamic Links, Invites, Notifications & Remote Config
push-уведомления относятся к категории бесплатных услуг.
Еще раз. С чего вы решили что уведомления платные?
Вы похоже перепутали Firebase Realtime Database и Firebase Cloud Messaging.
Насчет наших цен, мы у себя описали некие ограничения скорости в 100 в секунду на бесплатном тарифе, 500 на платном и выше если будет нужно. На деле же эти ограничения практически не действуют, даже на бесплатном тарифе сейчас можно более 3000 уведомлений FCM отправить за 1,5 секунды при условии что это массовая рассылка. Более того для интересных проектов мы предоставляем услуги бесплатно и делаем фичи если им это необходимо, надо лишь мне написать.
Также отвечу на предположение выше о 100 соединениях. Хорошо, 100 соединений, в среднем при открытом TLS соединении с гуглом 1000 уведомлений отправляется за 1 секунду. 100 соединений дает нам 100 000 уведомлений в секунду. Куда вам столько?
Да если вы шлете индивидуальные уведомления то гугл их обрабатывает значительно быстрее, примерно на уровне пинга до гугла.
У нас по логам 1 сообщение при существующем хендшейке ушло за 0.04 секунды. На один поток выходит 50 уведомлений в секунду. На 100 потоков это 5000 уведомлений в секунду. Это 18 миллионов уведомлений в час. Даже если каждый пользователь принимает 10 уведомлений в час это 1.8 миллионов активных пользователей.
Но коннекты на FCM не ограничены, также у гугла есть отправка через XMPP, которая должна быть в разы быстрее.
Отвечу сразу на несколько комментариев разных людей одним сообщением.
Нельзя отправить сообщение с клиента. То есть отправить запрос с помощью AJAX или веб-формы на сервер, чтобы тот отправил push-уведомление нам на клиентскую сторону. Не работает.
Можно. Работает: https://gauntface.github.io/simple-push-demo/.
Не смотря на заявленную поддержку Firefox, в нем уведомления не работают.
Работают. Проверял на Windows и Android.
Честно говоря больше интересует, как можно реализовать свой собственный сервер уведомлений, а не использовать сторонние.
Смотря что подразумевается под сервером.
См.: https://github.com/mozilla-services/autopush.
Есть отличный учебник по Web Push — https://web-push-book.gauntface.com.
К этой книге прилагается демонстрационный проект на Node.js: https://github.com/gauntface/web-push-book/tree/master/src/demos/node-server.
Использовать Firebase Cloud Messaging не обязательно, есть Web Push Libraries. Для Node.js: https://github.com/web-push-libs/web-push, для PHP: https://github.com/web-push-libs/web-push-php.
Библиотека Firebase скрывает в себе много тайн и её исследование могло бы дать ответы на некоторые вопросы, но это уже выходит за рамки этой статьи.
А жаль, там много интересного. ) Думаю, я созрел для своей первой статьи для Хабра. :)
Можно. Работает: https://gauntface.github.io/simple-push-demo/.
Работают. Проверял на Windows и Android.
Как мне уже объяснил iSage и я сам об этом подозревал — это Firebase не может отправлять уведомления, а если реализовывать push-уведомления нативными средствами, то все работает. Что у вас и сделано.
А жаль, там много интересного. ) Думаю, я созрел для своей первой статьи для Хабра. :)
Я вижу что описанного материала многим недостаточно. И хотел бы написать статью/продолжение в которой описать больше технических тонкостей и альтернативных реализаций.
Готов уступить вам эту тему.
Попробуйте Firebase Cloud Messaging JavaScript Quickstart и отпишитесь здесь о результате.
Проверял отправку со стороны клиента в браузере с помощью Fetch на Chrome и Firefox, на Windows и Android — всё работает.
Форкнул репозиторий и открыл на GitHub Pages. Протестировал через curl в Chrome и Firefox на Windows. Результат, мягко говоря, ошеломляет.
В Chrome все доходит как и должно и уведомление отображается. В Firefox уведомление тоже доходит, но не отображается. Отрабатывает метод messaging.onMessage() на странице и печатает тело уведомления в блоке #messages. Через fetch я получил тот же результат. В Chrome этот метод не отрабатывает.
Получается в Firefox нужно использовать метод messaging.onMessage() и в нем реализовывать показ уведомления вручную. Поскольку этот метод реализован на странице, а не в Service Worker, то мы сталкиваемся с рядом проблем:
- Нельзя получить уведомление если сайт не открыт в данный момент;
- Нельзя получить уведомление при закрытом браузере;
- Если сайт открыт в нескольких вкладках, то скрипт отрабатывает во всех вкладках.
Это лишь результаты беглого осмотра. Возможно я что-то упустил. У вас другие результаты?
И спасибо за ссылку. Добавил в статью.
PS: Странно то что у меня и без messaging.onMessage() в Firefox уведомления иногда отображались.
В Chrome этот метод не отрабатывает.
Какой именно метод?
К этому проекту прилагается видео https://youtu.be/BsCBCudx58g, в котором подробно объясняется, что к чему.
Обратите особое внимание на примечание о фокусе на странице https://github.com/firebase/quickstart-js/tree/master/messaging:
When the app has the browser focus, the received message is handled through theonMessagecallback inindex.html. When the app does not have browser focus then thesetBackgroundMessageHandlercallback infirebase-messaging-sw.jsis where the received message is handled.
The browser gives your app focus when both:
- Your app is running in the currently selected browser tab.
- The browser tab's window currently has focus, as defined by the operating system.
Следует также принять во внимание, что поведение одного и того же браузера на разных платформах может различаться. Например, Firefox для Android и Mac могут после закрытия работать в фоновом режиме и, соответственно, принимать push-уведомления, а Firefox для Windows — нет.
Можно передавать сообщения из service worker'а на страницу: https://web-push-book.gauntface.com/chapter-05/04-common-notification-patterns/#message-page-from-a-push-event
Советую всё-таки прочитать книгу https://web-push-book.gauntface.com полностью, в ней есть ответы почти на все вопросы о web push. ;)
Точно. Вся проблема была в messaging.onMessage(). Теперь я понял почему не работало без него. Добавил обработчик и сразу все, везде заработало.
Спасибо большое.
// регистрируем пустой ServiceWorker каждый раз navigator.serviceWorker.register('messaging-sw.js');
// запрашиваем права на показ уведомлений если еще не получили их Notification.requestPermission(function(result) {
Регистрировать каждый раз ещё один пустой service worker со своим собственным жизненным циклом только для того, чтобы показать уведомление — костыль. Так как мы используем Firebase Cloud Messaging, то в момент вызова messaging.onMessage у нас уже должен быть зарегистрирован service worker firebase-messaging-sw.js с областью видимости /firebase-cloud-messaging-push-scope, и можно использовать его.
Насколько я понимаю, запрашивать права на показ уведомлений в messaging.onMessage тоже не нужно.
Таким образом, messaging.onMessage должен выглядеть как-то так:
messaging.onMessage((payload) => {
navigator.serviceWorker.getRegistration('/firebase-cloud-messaging-push-scope').then((registration) => {
registration.showNotification(payload.notification.title, payload.notification);
});
});Кстати, есть ещё отличная книга о service workers — https://serviceworke.rs, в ней есть раздел о web push — https://serviceworke.rs/web-push.html с примерами использования https://github.com/web-push-libs/web-push.
На сколько мне известно, нет возможности посмотреть статистику по доставке сообщений.
Можно узнать, сколько push-уведомлений было доставлено, открыто и закрыто, добавив в service worker обработчики событий push, notificationclick и notificationclose (пример: service-worker.js) и отправляя данные в Google Analytics с помощью протокола передачи статистических данных Measurement Protocol (пример: analytics-sw.js).
На основе этого кода сделал уведомления на своем сайте. Заметил, что в опере уведомления не приходят, хотя ошибки при отправке нет.
Вернулся сюда, открыл демо-проект, получаю токен, жму Send и тут начинают прихоодить уведомления с моего сайта, ну и последним приходит тестовое.
Копаю дальше и нашел закономерность: если после получения токена закрыть браузер и затем открыть, токен уже имеется, но уведомления не приходят. Если удалить токен и нажать «Register» для получения нового, то получаю ошибку «Error An error occurred while retrieving token.».
После перезагрузки браузера и нажатия «Register» новый токен получается и уведомления успешно приходят до тех пор, пока опять браузер не перезагрузишь.
Ну и каждый раз, когда получаю новый токен, доходят запоздавшие уведомления с моего сайта, если они были в это время.
У кого-нибудь еще такое в опере наблюдается?
вдруг комуто актуально)
работает вообще без зависимостей и строних библиотек
но нужен доступ к proc_open() и работающий бинарник
bin/openssl
для парсинга asn.
вот код:
github.com/aaarkadev/simpl_webpush/commit/9b277414bc3e6a1885f8ec9da5ee5c54271b92c6
пример:
```
$wpObj=new simpl_webpush();
echo $wpObj->get_curl_cmd('https://updates.push.services.mozilla.com/wpush/v2/gAAAAABZ1M11111111_h2hs47YE6u6dYJ3JN90HhF11111ORtCnJfASwcKZZYulq5ZgS');
```
В момент, когда уведомление вылетело на экран. По нему можно кликнуть и откроется страница браузера. Но если попытаться кликнуть по уведомлению из шторки уведомлений Windows, то оно просто пропадает, а страница не открывается. Есть идеи как это исправить?
>> будем использовать PHP с расширением cURL
это было больно
А что, cURL это сложно? Или вы имеете что-то против конкретно PHP?
Приведенный пример легко портируется на любой популярный язык программирования будь то Python, Java, Node.js или Go. Можно и через bash пуши отправлять (пример).
Прошу прощения за некро, но я ничего не понял структурированной и понятной информации действительно мало.
Сначала речь идёт о том что мы напишем только клиента, а функции сервера будет выполнять этот Messaging. А потом появляется код на PHP.... Т.е. какой-то отдельный бэкенд всё-таки нужен? Или таки можно без него?
Давайте на примере. Допустим, хочу создать самый простой в мире чат:
пользователь пишет сообщение, отправляет, Firebase записывает Json в БД;
при появлении в БД нового сообщения (а также при инициализации приложения: только зашёл в чат или открыл свёрнутое окно) приложению приходит уведомление, оно выкачивает N последних сообщений и отображает их пользователю.
Это всё! Казалось бы, предельно просто, но я целый день читал эту доку, но так и не понял: можно или нет? И куда чего писать?
Я понимаю что "так не делают" ибо:
безопасность: нужна авторизация и всё такое;
нужен механизм подписки на разные чаты;
нужен сервис, который будет, например, чистить базу: если мы отображаем только N последних сообщений, нет нужды хранить остальные.
Но! Если решать задачу именно так как я описал, можно ли решить её только средствами Firebase, Firebase Cloud Messaging и клиента (который в браузер поступает с вэб-сервера, умеющего только раздавать "статику")? И если можно, какая м.б. "архитектура" у этого клиента?
PS: если можно, помедленнее, я во фронте овощ :)
Web PUSH Notifications быстро и просто