Комментарии 6
Обратите внимание на то, что push-сервисы — это сторонние службы, которые вы, как разработчик веб-приложения, не контролируете.Почему нельзя использовать свой же сервер, с которого загружается приложение?
Хотелось бы заменить в приложении polling на push, но использовать сервера Гугла в качестве MITM как-то не прельщает.
Судя по статье, сообщения приходят на push-сервер зашифрованными, а расшифровать их может только браузер, и всё, что может сделать Google, это не доставить сообщение или доставить его несколько раз. Поправьте меня, если я ошибаюсь.
Заменить polling на push можно с помощью веб-сокетов. И polling, и веб-советы работают, только когда сайт открыт, и не требуют участия третьей стороны.
Все статьи про push-уведомления начинаются с «зарегистрируйтесь в FCM», «получите аккаунт Pusher» или подобных предложений. А у вас в статье не требуется нигде регистрироваться, браузер сам получает данные для отправки уведомлений (объект PushSubscription). В чём подвох, и почему возникает потребность в использовании конкретного стороннего сервиса?
Хочу в наш проект прикрутить push, возник вопрос:
— На сайт клиенты входят под логином и паролем
— Внутри мемберки делаем подписку на push уведомления
— Клиент подписывается, мы в базу себе сохранили его ключи вместе со связью id клиента, тк мы хотим слать персонифицированные уведомления
— Наш клиент1 дал своему другу, клиент2 своей устройство, и уже другой клиент под своим логином паролем зашел в мемберку. Еще раз предлагать подписку, получается нет смысла? Тк разрешение от этого браузера у нас есть уже.
Получается что у нас в базе есть список браузеров авторизованых, и список клиентов которые могут пользоваться одним и тем же браузером.
Также у одного клиента может быть несколько браузеров.
И при отсылке пуша надо применить какую то логику, чтоб решить в какой браузер что слать и какой предположительно клиент увидит сообщение (последний, или тот что чаще всех пользуется).
Верно ли я понимаю технологию?
— На сайт клиенты входят под логином и паролем
— Внутри мемберки делаем подписку на push уведомления
— Клиент подписывается, мы в базу себе сохранили его ключи вместе со связью id клиента, тк мы хотим слать персонифицированные уведомления
— Наш клиент1 дал своему другу, клиент2 своей устройство, и уже другой клиент под своим логином паролем зашел в мемберку. Еще раз предлагать подписку, получается нет смысла? Тк разрешение от этого браузера у нас есть уже.
Получается что у нас в базе есть список браузеров авторизованых, и список клиентов которые могут пользоваться одним и тем же браузером.
Также у одного клиента может быть несколько браузеров.
И при отсылке пуша надо применить какую то логику, чтоб решить в какой браузер что слать и какой предположительно клиент увидит сообщение (последний, или тот что чаще всех пользуется).
Верно ли я понимаю технологию?
Возник вопрос, а как узнать подписан ли уже браузер клиента на push?
Ставить ему куку и по ней ориентироваться, или тут есть какой то иной метод?
А если по куке, и он например почистил куки сайта и мы ему 2й раз предлагаем подписку, что произойдет?
Ставить ему куку и по ней ориентироваться, или тут есть какой то иной метод?
А если по куке, и он например почистил куки сайта и мы ему 2й раз предлагаем подписку, что произойдет?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как работает JS: веб push-уведомления