iOS发送推送与APNs Auth Key:突然"403 Forbidden:{"reason":"InvalidProviderToken"}"

Question

我正在发送带有APNs Auth Key("永不过期")的推送通知,这种通知效果很好,直到我突然得到

403 Forbidden: {"reason":"InvalidProviderToken"}

作为发送推送通知时的响应.当它工作一次并突然间没有失效日期时,可能是什么原因？与此同时,它再次推动了一些推动,但现在我再次得到错误...有没有其他人经历过这个？

编辑

~~不确定,但似乎这只发生在Ubuntu服务器上,而不是在我的本地(OS X)机器上...~~

Answer 1

我在几种情况下看到过这种情况：

重新提交过期的提供者令牌似乎将令牌列入黑名单，并导致后续InvalidProviderToken拒绝而不是ExpiredProviderToken拒绝。检查您的日志以获取令牌到期消息。检查您的系统时钟以确保您没有生成带有倾斜时间戳的令牌。
提交到无效主题将使连接上的所有提供者令牌无效（甚至以前有效的令牌）。只提交密钥绑定的主题，并且每个连接只使用一个密钥。

Answer 2

使用相同的连接向不同的团队 ID 发送推送时，我们遇到了完全相同的问题。重现的步骤是：

打开与 APNS 的连接并使用相同的连接：
将基于令牌的推送发送到com.companyA.xxx团队 id 的主题1234：APNS 成功接受并交付推送。
向io.companyB.xxx团队 id主题发送基于令牌的推送5678：APNS 响应HTTP 400 BadRequest The device token does not match the specified topic
再次向io.companyB.xxx团队 id 的主题发送基于令牌的推送5678：APNS 响应HTTP 403 Forbidden: the provider token is not valid or the token signature could not be verified。

在此之后，无法发送任何推送，并且必须关闭并重新打开连接。

我们最终采取的解决方法是为每个团队 id打开一个连接。该APNS文件没有提到这样的事情，所以我认为这是一个错误，我开了一个bug报告。

Answer 3

苹果的 APN文档说：

APNs 仅支持使用 ES256 算法签名的提供商身份验证令牌。不安全的 JWT [JSON Web 令牌] 或使用其他算法签名的 JWT 将被拒绝，并且您的提供商服务器会收到 InvalidProviderToken (403) 响应。

所以，看来问题不在于你的auth kiey；而是在于你的auth kiey。这实际上是从您的密钥生成的网络令牌的问题。