anomalist
1 year ago
1 changed files with 70 additions and 0 deletions
@ -0,0 +1,70 @@ |
|||
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. |
Loading…
Reference in new issue