1

Is push support in Service Workers dependant on Firebase (and Apple's equivalent)? All the tutorials I find have a step where you register a Firebase account, but for our webapp this is a no-go as it will be used at premises without internet access.

I would have assumed that it was possible to register a URL that conformed to some protocol that the OS would register with, but I cannot find any information of the sort.

If it is the case that one needs internet access for service worker push support I assume the only option for a web app to receive background notifications is to wrap it in a native web view and use that to call out to on-premise services.

anthumchris
  • 8,245
  • 2
  • 28
  • 53
oligofren
  • 20,744
  • 16
  • 93
  • 180

2 Answers2

1

Internet or third-party push services are not required if you provide a local push service on a local network server that can be accessed via HTTPS URL from clients' browsers. Your local push service needs to implement the W3C Push API specification, and you could also search the web or GitHub for an open-source push service in the language of your choice.

The browsers would would require an HTTPS URL that resolves to a server on your network via hostname or IP, so self-signed SSL certificates would most likely be used. The devices would need the certificates (or CAs) implicitly trusted or explicitly added as a trusted CA/cert.

anthumchris
  • 8,245
  • 2
  • 28
  • 53
  • Yo, sorry, but I am not sure how I managed to accept the answer. Was on my phone. The thing is, I don't think this is correct. I have now looked at the source of several libs, and they all rely on FCM, GCM, etc for the last-mile delivery of the message. You can for instance try out https://serviceworke.rs/push-payload demo and view the network traffic for `/sendMessage`. The subscription data always has a `endpoint` with the domain `fcm.googleapis.com/fcm/...` when using Chrome. – oligofren May 14 '18 at 19:51
  • This also goes well with how the Java lib from the `web-push-libs` organization [explains how web push works](https://github.com/web-push-libs/webpush-java/blob/master/doc/UsageExample.md): `1. First the end user's web browser needs to establish a push channel with the browser manufacturer's push server. In the case of Firefox, this would be a Mozilla server, in Chrome's case, this would be a Google server. After this is done, a unique endpoint URL is sent to the browser, `. Feel free to prove me wrong, though! Nothing would be better :-) – oligofren May 14 '18 at 19:55
  • The Push API should be an open source specification that prevents vendor lock-in, and I recommend waiting for one of the Mozilla/Google engineers to chime in. Or send the spec authors the URL of this question via direct email (find them on the spec page). They're typically great and very helpful. – anthumchris May 14 '18 at 20:04
  • I just tried visiting the demo above using Firefox, and as explained, it too registered with the web push service using Firefox' own server as the endpoint: `subscription {…} endpoint https://updates.push.services.mozilla.com/wpush/v2/gAAA...` – oligofren May 14 '18 at 20:05
  • Thanks for the tip. The Push API is an open spec that prevents vender lock in, and having each browser use its own trusted server doesn't change that, but being able to replace it for your own would be great. I'll try pinging one of them, thanks! – oligofren May 14 '18 at 20:07
  • Actually, I found the definitive answer in the spec, when finding [the definition](https://www.w3.org/TR/push-api/#dfn-push-services) of a _push service_: "`There is only one push service per user agent and it cannot be changed from the default value. This limitation is due to a variety of performance-related concerns, including the complexity of running reliable push services and the impact on battery lifetime if there were an unbounded set of push services to which a device could connect.`". So no :( – oligofren May 14 '18 at 20:32
  • 1
    That spec link is from version Dec 2017, and the [Push Service in Editor's Draft](https://w3c.github.io/push-api/#push-service) is more up to date and tracks the [issues/questions filed on GitHub](https://github.com/w3c/push-api/issues?q=is%3Aissue). Don't give up and use the [mailing list](https://lists.w3.org/Archives/Public/public-webapps/) or file an issue. It's a great suggestion to implement. [Issue #293](https://github.com/w3c/push-api/issues/293) is a good example of how the spec changed – anthumchris May 15 '18 at 00:35
  • Great find! I wonder if anyone implemented this yet, but this looks promising. – oligofren May 15 '18 at 06:17
0

tldr; it depends on your browser, as it needs to be configured on a per-browser level. As of May 2018, it seems as if Firefox is the only one that lets you configure the service url. For everyone else, you need internet for push messages to be delivered.

The December 2017 Push API specification (which is the official one as of May 2018), says this:

The term push service refers to a system that allows application servers to send push messages to a webapp. A push service serves the push endpoint or endpoints for the push subscriptions it serves.

There is only one push service per user agent and it cannot be changed from the default value. This limitation is due to a variety of performance-related concerns, including the complexity of running reliable push services and the impact on battery lifetime if there were an unbounded set of push services to which a device could connect.

In April 2018 they relaxed this requirement and the spec now allows for configuring a different provider.

I also recommend reading this the dumbed-down version of how webpush works, where the main points are as follows:

  1. First the end user's web browser needs to establish a push channel with the browser manufacturer's push server. In the case of Firefox, this would be a Mozilla server, in Chrome's case, this would be a Google server. After this is done, a unique endpoint URL is sent to the browser, and the browser generates a public and private key pair which is stored internally in the browser. The browser then makes a public key and a user authentication secret used by your server to E2E encrypt messages to the user's browser.
  2. The browser sends the public key, authentication secret and endpoint URL to your server, and the server stores this somehow (in a database, in memory, a file, whatever).
  3. When the time comes that the server wishes to send a push message, it retrieves the stored information on the push message subscription and creates an encrypted message with the public key and user authentication. Then the server contacts the endpoint URL and tells it to push some content to the user agent.
  4. Given everything looks OK, the push server pushes the message to the user's browser.
Community
  • 1
  • 1
oligofren
  • 20,744
  • 16
  • 93
  • 180