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