You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
71 lines
3.8 KiB
71 lines
3.8 KiB
1 year ago
|
Web Push notifications is a web browser messaging protocol defined by the W3C.
|
||
|
|
|
||
|
|
Discussions of this interesting technology are clouded because of a terminological
|
||
|
|
morass.
|
||
|
|
|
||
|
|
To understand how Web Push operates, we need to observe that are three (and
|
||
|
|
potentially four) parties involved. These are:
|
||
|
|
|
||
|
|
1) The user's web browser. Let's call that BROWSER
|
||
|
|
2) The Web Push Service Provider which is operated by the organization controlling the
|
||
|
|
web browser's source code. Here named PROVIDER. An example of a PROVIDER is
|
||
|
|
FCM (Firebase Cloud Messaging) which is owned by Google.
|
||
|
|
3) The Web Application that a user is visiting from their web browser. Let's call this the
|
||
|
|
SERVICE (short for Web Push application service)
|
||
|
|
[4) A Custom Web Push Intermediary Service, either third party or self-hosted. Called
|
||
|
|
INTERMEDIARY here.]
|
||
|
|
|
||
|
|
The workflow works like this:
|
||
|
|
|
||
|
|
BROWSER visits a website which has a SERVICE.
|
||
|
|
|
||
|
|
The SERVICE asks BROWSER for its permission to subscribe to messages coming
|
||
|
|
from the SERVICE.
|
||
|
|
|
||
|
|
The BROWSER receives a data structure from SERVICE called a VAPID (Voluntary
|
||
|
|
Application Server Identification).
|
||
|
|
|
||
|
|
The VAPID is a specification used to identify the application server (i.e. the SERVICE
|
||
|
|
server) that is sending push messages to a push service. It's an authentication
|
||
|
|
mechanism that allows the server to demonstrate its identity to the push service, by use
|
||
|
|
of a public and private key pair. These keys are used by the SERVICE in encrypting
|
||
|
|
messages being sent to the BROWSER, as well as being used by the BROWSER in
|
||
|
|
decrypting the messages coming from the SERVICE.
|
||
|
|
|
||
|
|
If the BROWSER accepts and grants permission to subscribe to receiving from the
|
||
|
|
SERVICE Web Push messages, then the BROWSER makes a subscription request to
|
||
|
|
PROVIDER which creates and stores a special URL for that BROWSER. The
|
||
|
|
PROVIDER sends this URL back to the BROWSER. The BROWSER will then use that
|
||
|
|
URL to check for incoming messages by way of a special software named a "service
|
||
|
|
worker". The BROWSER also sends this URL back to SERVICE which will use that
|
||
|
|
URL to send messages to the BROWSER via the PROVIDER.
|
||
|
|
|
||
|
|
Ultimately, the actual process of receiving messages varies from BROWSER to
|
||
|
|
BROWSER. Approaches vary from long-polling HTTP connections to WebSockets. A
|
||
|
|
lot of handwaving and voodoo magic. The bottom line is that the BROWSER itself
|
||
|
|
manages the connection to the PROVIDER whilst the SERVICE must send messages
|
||
|
|
via the PROVIDER so that they reach the BROWSER.
|
||
|
|
|
||
|
|
Now to address the issue of receiving notification messages on mobile devices.
|
||
|
|
It should be noted that Web Push messages are only received when BROWSER is
|
||
|
|
open, except in the cases of Chrome and Firefox mobile BROWSERS. In iOS the
|
||
|
|
mobile application (in our case a PWA) must be added to the Home Screen and
|
||
|
|
permissions must be explicitly granted that allow the application to receive push
|
||
|
|
notifications. Further, with an iOS device the user must enable wake on notification to
|
||
|
|
have their device light-up when it receives a notification (https://support.apple.com/enus/HT208081).
|
||
|
|
So what about #4? - The INTERMEDIARY. Well, It is possible under very special
|
||
|
|
circumstances to create your own Web Push PROVIDER. The only case I've found so
|
||
|
|
far relates to making an Android Custom ROM. (An Android Custom ROM is a
|
||
|
|
customized version of the Android Operating System.) There are open source
|
||
|
|
IMTERMEDIARY products such as UnifiedPush (https://unifiedpush.org/) which can
|
||
|
|
fulfill this role. If you are using iOS you are not permitted to make or use your own
|
||
|
|
custom Web Push PROVIDER. Apple will never allow anyone to do that. Apple has
|
||
|
|
none of its own.
|
||
|
|
|
||
|
|
It is, however, possible to have a sort of proxy working between your SERVICE and
|
||
|
|
FCM (or iOS). Services that mash up various Push notification services (like
|
||
|
|
OneSignal) can perform in the role of such proxies.
|
||
|
|
|
||
|
|
#4 -The INTERMEDIARY- doesn't appear to be anything we should be spending our
|
||
|
|
time on.
|