Plans for web push features?

[jake-bickle]

It's my understanding that uniqush-push provide a simple means of sending push notifications to android, apple, and kindle devices and has no means of sending web push notifications.

Are there any plans to support this? Does that lie outside the scope of uniqush-push? I ask this because other platforms (such as OneSignal) do provide web push services.

[TysonAndre]

Related to #117

There's no real objection to web push features, it's just that the maintainers haven't had the free time to implement and qa the features to provide a complete implementation (e.g. does it vary between browsers/OSes, are there edge cases in networking, how has it changed since 2016, security concerns with user-provided endpoints, etc).

It's also a complicated spec.

I'd thought at least one of the maintainers would be involved in an application that used web push, but they had ended up working on other projects instead.

Miscellaneous findings that may help with implementing this in uniqush-push

Uniqush would have to handle unsubscriptions, and the response payload differs between platforms. https://developers.google.com/web/fundamentals/push-notifications/common-issues-and-reporting-bugs mentions some of the differences between Chrome and Firefox - I don't know about edge/opera/safari. Checking the HTTP response code with https://developers.google.com/web/fundamentals/push-notifications/common-issues-and-reporting-bugs#http_status_codes may work on more/all platforms? https://developers.google.com/web/fundamentals/push-notifications/sending-messages-with-web-push-libraries mentions some relevant details

To determine the type of error from a push service it's best to look at the status code. Error messages vary between push services and some are more helpful than others.

In this example, it checks for status codes 404 and 410, which are the HTTP status codes for 'Not Found' and 'Gone'. If we receive one of these, it means the subscription has expired or is no longer valid. In these scenarios, we need to remove the subscriptions from our database.

And https://developers.google.com/web/fundamentals/push-notifications/display-a-notification would be useful for mapping uniqush's property names to, for <uniqushhost>/push

• https://github.com/SherClockHolmes/webpush-go seems up to date, but that only handles sending it - checking what a response means (e.g. a subscription is no longer valid and can be deleted from redis) is not part of that library
• https://github.com/SherClockHolmes/webpush-go/tree/master/example has an example of this. If I generate a public key with webpush.GenerateVAPIDKeys() in Chrome, I get something like {"subscription":{"endpoint":"https://fcm.googleapis.com/fcm/send/<data>","expirationTime":null,"keys":{"p256dh":"<data>","auth":"<data>"}}}. In Firefox on Linux, {"subscription":{"endpoint":"https://updates.push.services.mozilla.com/wpush/v2/<data>","keys":{"auth":"<data>","p256dh":"<data>"}}}. And probably various other services for opera/safari/edge and others.
• I see the same question I'm asking in https://stackoverflow.com/questions/52252877/which-host-ports-should-be-open-for-web-push as well. Maybe a configurable whitelist of additional hosts would help
• Resolving IP addresses, using those with a manually set "Host:" header, and making sure they aren't internal IP blocks (e.g. localhost) would help somewhat with the security concerns.
• Setting connect timeouts/request timeouts and avoiding redirects would help avoid networking edge cases

A guess of common major endpoints, which will go out of date or may only apply to receiving, not sending:

*.notify.windows.com
android.googleapis.com
fcm.googleapis.com
updates.push.services.mozilla.com
gateway.push.apple.com

If uniqush-push were to be set up behind a firewall that limits access to only a few external ips, that may cause problems. It may be useful to allow it to configure an https proxy and have all web pushes go through that proxy