Webpush not triggering notifcations to safari

[deepak469]

The web-push notifications are working fine for chrome and firefox, but not working for safari v16 browser.

[VanessaCarpes]

@deepak469 same problem here. Any updates?

[VanessaCarpes]

I found this forum saying we should use the HTTP/2 based interface: https://developer.apple.com/forums/thread/680366

[kenkc]

Anyone else have a solution to this? Tried using HTTP/2 by changing the dependencies and rebuilding. No joy. I think HTTP/2 is a requirement for APN endpoints anyway. The documentation for using the Push API endpoints states both are supported.

I keep getting a 403 returned with reason BadJwtToken. The reasons for this are listed in the Apple documentation https://developer.apple.com/documentation/usernotifications/sending_web_push_notifications_in_safari_and_other_browsers but I’m not sure what could be the problem with the JWT.

However, when I test the JWT in jwt.io I get an invalid signature error. Could this be the issue?

[aistomin]

In my case the problem was that I was sending "mail@example.com" as a subject claim. According to the documentation in the comment above, this 403 BadJwtToken error can be caused, among other reasons, by "The JWT subject claim isn’t a URL or mailto:.". So, changing my subject parameter to "mailto:mail@example.com" fixed the problem. Now it works. I've tested it on MacOS (13.2.1 (22D68)) with the Safari(Version 16.3 (18614.4.6.1.6)), Chrome(Version 110.0.5481.177 (Official Build) (arm64)) and Firefox(110.0 (64-bit)).

[knalli]

Yeah, also handled (and solved) this for a demo yesterday.

Although the spec/rfc says the subject claim MAY be required, Apple seems to changed it to a MUST for their service.

As @aistomin already pointed out, the Apple developer documentation guide claims this actually. Overseen this also at first.

BadJwtToken | The JWT subject claim isn’t a URL or mailto:.

Of course you should not use an example mail address uri, but a real one. IMHO this can be technical contact address like your domain have some, just in case the push service have to contact you in situations.

[aistomin]

@knalli

Although the spec/rfc says the subject claim MAY be required, Apple seems to changed it to a MUST for their service.

Actually I already had the same problem with Firefox in the past.

[knalli]

Ah, right. That was on my todo list, but also solved now. Thanks.

Although being slightly off-topic, but the actual problem is not to comply with the specific push server implementation of the vendor (here Apple). Is anyone aware of documents from Google/Mozilla/Microsoft like the one from Apple? Everything I found so far are different and incomplete docs/guides from third parties ("community"), which do not comply with the actual vendor implementations. Maybe it be worth to collect them at a place.

[kenkc]

Thanks guys. Really can't believe this was so simple in the end. I actually did have subject, but it was malformed (or at least malformed according to Apple's restrictions). My subject was in the format "mailto: \mail@example.com\". Apple doesn't like the space or the angle brackets. That's a few days I won't get back!

[VanessaCarpes]

@aistomin thank you so much for the solution, now my safari works like a charm but on Chrome I get: crypto-key header had invalid format. crypto-key header should have the following format: p256ecdsa=base64(publicApplicationServerKey)

Did you face this issue? Did you make another change in the lib to send using HTTP/2?

[aistomin]

@VanessaCarpes no, I didn't do any changes besides this sub parameter for months and I'm using latest publicly available version 5.1.1. As I mentioned before, I used MacOS (13.2.1 (22D68)) for testing and it works for me with Safari(Version 16.3 (18614.4.6.1.6)), Chrome(Version 110.0.5481.177 (Official Build) (arm64)) and Firefox(110.0 (64-bit)).

[knalli]

Well, afaik the requirement for HTTP/2 is for the APNS of (native) apps only, in case of Apple api.push.apple.com. That is another endpoint, the web push endpoints are currently web.push.apple.com.

Both the standard and the given documentation guide by guide clearly state HTTP/1.1 have to work. Even the client-server connection (i.e. browser fetching subscriptions) seems to rely in HTTP/1.1.

Given the error message, I would suggest to recheck the followings

• recheck how to create server public / private key
• ensure not to change the keys while developing -- both server keys and client keys must match (a subscription created with an older server key is outdated)
• ensure the converting between byte[] and String is correctly done with the correct Base64 encoder/decoder.

Also for the records: iOS 16.4b, PWA and Web Push is finally working.

[aistomin]

@VanessaCarpes I've created a tiny demo app here: https://github.com/aistomin/webpush-demo This code I've tested just now with Chrome and it works. You may try it with your configuration to see how it goes in the isolated environment. I hope it will help you to find what is the cause of your problem.

[VanessaCarpes]

Yes, using this lib works perfectly, but using the impl to send HTTP/2 I had that issue I mentioned before just on Chrome, Safari worked. For now, I'll stay with this lib ;) Thank you so much for the tips.

[martijndwars]

Closing this issue, as the problem seems to be resolved.