Отслеживание уведомлений о Pu sh - PullRequest
0 голосов
/ 04 марта 2020

Я недавно внедрил уведомления pu sh в мое приложение Angular. Все работает как положено. Я спрашиваю у пользователя его разрешение и отправляю SubscriptionInfo в мой django бэкэнд, где я храню его в базе данных для актуальных уведомлений. SubscriptionInfo выглядит примерно так:

{
  "endpoint": "https://fcm.googleapis.com/fcm/send/cbx2QC6AGbY:APA91bEjTzUxaBU7j-YN7ReiXV-MD-bmk2pGsp9ZVq4Jj0yuBOhFRrUS9pjz5FMnIvUenVqNpALTh5Hng7HRQpcUNQMFblTLTF7aw-yu1dGqhBOJ-U3IBfnw3hz9hq-TJ4K5f9fHLvjY",
  "expirationTime": null,
  "keys": {
    "p256dh": "BOXYnlKnMkzlMc6xlIjD8OmqVh-YqswZdut2M7zoAspl1UkFeQgSLYZ7eKqKcx6xMsGK7aAguQbcG9FMmlDrDIA=",
    "auth": "if-YFywyb4g-bFB1hO9WMw=="
  }
}

Теперь во время тестирования серверная часть выдает ошибку 410 GONE при отправке подписки (я не знаю почему, удаляя строку в серверной части и повторно разрешая уведомления в веб-интерфейсе исправили проблему), указывая, что подписка больше не действительна и должна быть удалена. Конечно, я должен как-то проинформировать об этом интерфейс, удалить «локальный» токен уведомления и повторно запросить разрешение у пользователя. Информирование о веб-интерфейсе не является проблемой, однако, поскольку один пользователь может иметь несколько устройств (или браузеров) для получения уведомлений, я должен как-то проверить в веб-интерфейсе, какая подписка должна быть «продлена». Поэтому я подумал об использовании какого-то типа uid (состоящего из имени браузера, версии и т. Д. c), однако это создает несколько проблем:

  • Что если браузер обновится? На объект подписки это не должно повлиять, оно все равно будет действительным, верно?
  • Недостаточно будет использовать только имя браузера, поскольку пользователь может использовать два устройства с одним браузером

Затем я подумал об использовании некоторой информации, уже содержащейся в SubscriptionInfo, такой как конечная точка или некоторая часть ключей. Конечная точка обязательно должна быть разной для каждой подписки, верно? При запросе разрешения на уведомление («генерация» SubscriptionInfo) каждый раз получал разные конечные точки, разрешающие уведомления, верно? Вот (примерно) как бы я следил за отслеживанием состояний уведомлений:

  • Когда пользователь входит в систему, проверьте, является ли Notification.permission granted:
  • Если нет , запросите разрешение и отправьте SubscriptionInfo на сервер.
  • Если да, проверьте сервер, если SubscriptionInfo помечен как GONE / FAILED независимо от того (или может быть удален)
  • Если да, каким-то образом (на самом деле, как?) удалите «локальную» подписку и повторно спросите пользователя.

Может быть, я слишком обдумываю это, потому что не могу найти что-либо о подобных проблемах , Или subscriptionInfo настолько постоянен, что он становится недействительным только после того, как пользователь вручную аннулирует разрешение на уведомление, так что достаточно просто удалить SubscriptionInfo в серверной части?

...