web-push-libs. But the underlying mechanism is a web service request over HTTP.
The push service receives your request, authenticates it, and routes the push message to the appropriate client. If the client's browser is offline, the push service queues the push message until the browser comes online.
Each browser uses whatever push service it wants. You as a website developer have no control over that. This isn't a problem because the web push protocol request is standardized. In other words, you don't have to care which push service the browser vendor is using. You just need to make sure that your web push protocol request follows the spec. Among other things, the spec states that the request must include certain headers and the data must be sent as a stream of bytes.
You do, however, need to make sure that you're sending the web push protocol request to the correct push service. The PushSubscription
data that the browser returned to you during the subscription process provides this information. A PushSubscription
object looks like this:
{
"endpoint": "https://fcm.googleapis.com/fcm/send/c1KrmpTuRm…",
"expirationTime": null,
"keys": {
"p256dh": "BGyyVt9FFV…",
"auth": "R9sidzkcdf…"
}
}
The domain of the endpoint
is essentially the push service. The path of the endpoint
is client identifier information that helps the push service determine exactly which client to push the message to.
The keys
are used for encryption, which is explained next.
The data that you send to a push service must be encrypted. This prevents the push service from being able to view the data you're sending to the client. Remember that the browser vendor decides what push service to use, and that push service could theoretically be unsafe or insecure. Your server must use the keys
provided in the PushSubscription
to encrypt its web push protocol requests.
The push service provides a way to prevent anyone else from sending messages to your users. Technically you don't have to do this but the easiest implementation on Chrome requires it. It's optional on Firefox. Other browsers may require it in the future.
This workflow involves a private key and public key that are unique to your application. The authentication process roughly works like this:
endpoint
for the device, it associates the provided public key with the endpoint
.The web push protocol request spec also defines parameters that let you customize how the push service attempts to send the push message to the client. For example, you can customize:
Once you've sent the web push protocol request to the push service, the push service keeps your request queued until one of the following events happens:
When a client browser receives a pushed message, it decrypts the push message data and dispatches a push
event to your service worker. A service worker is basically JavaScript code that can run in the background, even when your website isn't open or the browser is closed. In your service worker's push
event handler you call ServiceWorkerRegistration.showNotification()
to display the information as a notification.