iOS Push Certs失敗原因爲「No」

Question

我們的應用程序現在使用iOS推送通知的生產證書。

我們經歷了幾輪推動工作，然後他們就停止工作。通常「停止工作」與某些服務器故障有關。然而，我們使用的服務器表示，我們仍然在起訴與創建證書時生成的p12相同的消息，但他們從Apple獲得錯誤代碼8，這意味着它是一個無效標記。

我重新生成證書和「髒」的配置文件/標識符重新加載服務器上的p12s和一切工作正常......一段時間。然後他們神奇地開始出現「錯誤代碼8」，我們不得不重新開始。

今天我注意到，我們的應用程序的以前的版本工作正常，但目前的版本不。它們都是使用相同的配置文件和/或企業配置文件構建的，兩者都使用相同的應用程序ID證書，都加載到TestFlight（僅供參考），並具有相同的與推送相關的代碼。

奇怪的是，當我使用舊版本時，我得到一個4xxxxx ...設備令牌（始終如一），並且當我使用新版本時，我始終從設備令牌獲取5xxxxx ...設備令牌蘋果（始終如一）。

我知道一個事實，即之前的版本先前已獲得5xxxx ...設備標記，因爲我在相當一致的基礎上檢查了該版本。

但是，我注意到我們的一些測試人員註冊了更多的設備令牌，而不是他們說的設備令牌，所以這個問題可能會持續很長時間，我錯誤地認爲這是另一個問題。

是什麼導致設備令牌具有一致但不同的數字？

什麼是設備令牌的解剖？

有沒有人有任何想法爲什麼完全相同的配置文件/標識符會突然停止工作的完全相同的推證書？

謝謝

Answer 1

設備令牌很少改變。我知道他們需要更改的唯一實例是升級iOS版本或從備份恢復設備。因此，對於不同版本的相同設備獲得不同令牌的事實可能意味着其中一個版本使用沙箱證書，而另一個版本使用生產證書。我能想到的唯一的其他解釋是，爲了測試舊版本，您從備份中恢復了設備，從而更改了其設備令牌。

從您的問題描述看來，您的數據庫似乎包含沙箱設備令牌和生產設備令牌的混合。他們混合不好。沙盒標記在生產環境中無效，反之亦然。

您應清除數據庫並開始從用戶那裏收集設備令牌，否則應找到導致無效令牌響應並刪除它們的所有令牌。

從蘋果公司的Technical Note：

最常見的問題是一個無效的設備令牌。如果來自沙盒環境的令牌來自 ，例如當您在內部測試 開發版本時，則無法將其發送到生產推送 服務。每個推送環境將爲同一設備或計算機發出不同的令牌。如果您將設備令牌發送到錯誤的環境中，則推送服務會將該設備令牌視爲無效令牌，並丟棄該通知。

注意：建議您爲每個推送環境運行您的 提供程序的單獨實例，以避免將設備令牌發送到錯誤環境的問題。