Can't seem to get this working on Safari

[zehawki]

Working fine on Chrome, FF, Opera, Edge etc tested on Win 10, Win 11 and Android - but not IoS Safari. Whatever I do, I get:

Push failed: 403 Forbidden
Response body:{"reason":"BadJwtToken"}

And this is reported by many people all over the place, so I am not the only one suffering with Apple the special snowflake.

Anybody has a clue what can be tried? The apple documentation says nothing much here: https://developer.apple.com/documentation/usernotifications/sending-web-push-notifications-in-web-apps-and-browsers

"The JSON web token (JWT) has one of following issues: The JWT is missing. The JWT is signed with the wrong private key. The JWT subject claim isn’t a URL or mailto:. The JWT audience claim isn’t the origin of the push service where you sent the request. The JWT expiration parameter is more than one day into the future."

I also changed the "sub" to "subject" in the vapid_claims (https://github.com/web-push-libs/pywebpush?tab=readme-ov-file#sending-data-using-webpush-one-call) since the Apple documentation mentions a "The JWT subject claim" in particular - but no luck.

[jrconlin]

Sigh. no, you're probably not the only one that's impacted by this. Apple tends to want things done their way, and don't really bother saying what sort of restrictions they have. (To be fair, everyone is kinda awful about that.)

I can't really debug this myself right now, so here are a few things I'd probably try:

1. VAPID has hard requirements for "aud" (which should point to the host (and port if it's not standard) of the recipient endpoint, e.g. "whatever.push.apple.com" Kind of annoying that they're not using a single load balancer in front of their servers, so the real endpoint might be "us-west1-apple-foo.push.apple.com". Might want to check that the aud you're specifying in the VAPID assertion block matches the endpoint.
2. Another fun one is that the exp has a limit of 24 hours. The problem is that "24 hours" can be a bit "fuzzy". For some, I usually suggest that they set the exp to UTC+20 hours. This usually helps with clock drift, although it does mean you can't cache your VAPID header as long. (Most folk just generate a new VAPID header on each request, so yeah, unless you're dumping TONS of push messages, it's probably not an issue.)
3. sub is a valid contact URL. This messes folk up. So you don't use bob@example.com, you use mailto:bob@example.com. (this is where mozilla is non-standard because if you have a VAPID header, we want you to include a sub field.
4. (and this is a dumb one if it's it), VAPID keys should be unpadded values. The t is a base64 encoded string that contains three parts, the first is the JWK, so it's in three parts, with the second being the base64 encoded assertion block. The k is the VAPID02 public key. (VAPID01 uses a different header to send the public key, which is why it's not as good.)

Those are the first round of things. The next round is a bit trickier.

VAPID has two versions, the pre-release and RFC version. in py_vapid this is VAPID01 (the old, crappy spec) vs VAPID02, the RFC version. pywebpush SHOULD be using only VAPID02and Apple SHOULD accept both, but who knows? Unfortunately, testing that out means that you're going to have to go in and use the calls directly. You can see what to do by looking at the webpush function, but basically, "Do the VAPID thing" to make the Authorization header, then Add that header as a parameter when calling Webpusher(...).send(...)

I don't really have any apple or ios devices I can test with right now, otherwise I'd do this myself. If someone else does, and is feeling motivated, I'd love to know what works so I can make the fix.

[zehawki]

@jrconlin Thank you profusely for the extremely detailed comments with things to try.

Strangely, its working fine today in our test environment, with absolutely no change being made to the code etc. All we did was redo the process all over again - uninstall the PWA, reinstall (ie add to home screen), register again for push notification - and its perfectly fine.

Which probably means that in our earlier trials the endpoint had expired - but then why is apple returning a 403 instead of a 404 The request contains an invalid :path value (https://developer.apple.com/documentation/usernotifications/sending-web-push-notifications-in-web-apps-and-browsers#Review-responses-for-push-notification-errors), which perhaps makes more sense, and what FCM does.

We'll try with more ios devices, then ipad and mac and see if its all A ok everywhere and report back on this thread.

[jrconlin]

Hmm...
I can't give you a solid answer for why you're seeing what you're seeing, but I can give you a bit of the general weirdness that we see.

The various bridge systems we use (FCM, APNs, etc.) work a bit like how we do. In short, a device registers an ID of some sort, that it then uses to check to see if there are messages from some central store. Because devices tend to not be permanently connected all the time, there's a storage system that holds undelivered messages, as well as some state information about the device. One of the problems is that determining is a device is "alive" can be surprisingly difficult, both for technical and non-technical reasons. So, what a LOT of systems do is just presume that the device that's currently at the bottom of Biscayne Bay is just "not checking in" instead of part of a growing ecosystem (well, there are barnacles growing on it).

What this means is that when and how a system determines a device is "Alive" and "responsive" can be weird and unintuitive, at best. This gets reflected in the response code that can get returned.

The very short answer for a lot of this is "Push is a Best Effort" delivery system. This is kinda true across the board. You shouldn't rely on push to control your nuclear reactor or pace maker. Systems will do their darndest to try and deliver things, but it's not always going to happen. There are ways to try and improve that, but you also run the risk of annoying your customers (or creeping them out, which can be far worse). Like pretty much every other form of communication, presuming failure can often be the best course.

FWIW, we're trying to work on some fixes to make our system more reliable, but even then, we're never going to hit 100%. My goal is to get to 90%, but even then there's going to be a lot of abandoned messages or messages that we try and send that disappear into the ether.

Best of luck identifying what's going on with your app. And yeah, I am REALLY interested in what you find out.