简体   繁体   English

应用转移后,用户会收到Apple Push Notification消息吗?

[英]Will users get Apple Push Notification Message after App Transfered?

We had implemented APNS in our app and it was working fine. 我们已经在应用程序中实现了APNS ,并且运行良好。 But now we have transferred this app to client's account. 但是现在我们已将此应用转移到客户的帐户。 And client has submitted new version of app to the app store using there account. 客户已使用该帐户向应用商店提交了新版本的应用。 So my questions are - 所以我的问题是-

  1. will old users with having older version of app and not updated new version of app yet (ie which was submitted from our account and in which APNS is configured with our account certificates and credentials) still get the push messages? 具有较旧版本的应用程序但尚未更新新版本的应用程序(即从我们的帐户提交的,使用我们的帐户证书和凭据配置了APNS的旧用户)是否仍会收到推送消息?

  2. will new users with having newer updated version of app (ie which is now submitted from client's account and in which APNS is configured with our account certificates and credentials) still get the push messages? 具有更新版本的应用程序(即现在已从客户帐户提交且已使用我们的帐户证书和凭据配置APNS的应用程序)的新用户是否仍会收到推送消息?

  3. .pem file for APNS was generated from our account (before app transferred) and after app transferred also this .pem file is used. APNS的.pem文件是从我们的帐户生成的(在应用转移之前),在应用转移之后,该.pem文件也被使用。 so do we need to create new .pem file for APNS using client's account ? 那么,我们是否需要使用客户帐户为APNS创建新的.pem文件?

Please guide me on these issue. 请在这些问题上指导我。

Thank you 谢谢

Below are my suggestions.. 以下是我的建议。

1) YES, users with older versions will get push notifications. 1)是,具有旧版本的用户将获得推送通知。

2) NO, users will not get push notifications. 2)不,用户不会收到推送通知。 As it is configured with your account. 由于它是使用您的帐户配置的。

3) YES, you need to create new .pem file with client account. 3)是,您需要使用客户帐户创建新的.pem文件。

You need to see push notifications enabled or not at clients account and need to generate .p12 and .pem using clients account for making new users receive push notifications... 您需要在客户帐户中查看是否启用了推送通知,并且需要使用客户帐户生成.p12和.pem,以使新用户收到推送通知...

Hope it helps you.. 希望对您有帮助。

in each app contains one private key, one public Key and one provisional profile . 每个应用程序中的包含一个私钥,一个公钥和一个临时配置文件。 this is used for identify the each project. 这用于标识每个项目。 so in here you are used the old .pem and old .p12 and old .provisional profile 所以在这里您将使用旧的.pem和旧的.p12以及旧的.provisional配置文件

-- now you are using the New provisional profile and .p12, so you need to create the new .pem file for APNS , thats surely works and solve your issue. -现在您正在使用新的临时配置文件和.p12,因此您需要为APNS创建新的.pem文件,这肯定可以解决您的问题。

1) yes, 2) yes, 3) no, you don't need to update the certificate. 1)是,2)是,3)否,您不需要更新证书。

Push notifications are routed based on an app's bundle identifier, so the Team ID does not enter into this at all. 推送通知基于应用程序的捆绑包标识符进行路由,因此团队ID根本不会输入。 In other words, transferring the app doesn't affect push notifications provided that you keep the existing bundle identifier. 换句话说,如果您保留现有的捆绑包标识符,则传输应用程序不会影响推送通知。

APNs TLS/SSL certificates are only for installing on your push server so it can connect to APNs. APNs TLS / SSL证书仅用于在推送服务器上安装,因此它可以连接到APNs。 The APNs TLS/SSL certificate is completely separate from the provisioning profile and code signing certificate you use when building your app or submitting it to the App Store. APNs TLS / SSL证书与您在构建应用或将其提交到App Store时使用的配置文件和代码签名证书完全分开。

Thus, after transferring an application, the push certificate created in the old account is still able to send notifications to your app, even after publishing another update. 因此,在转移应用程序之后,即使在发布另一个更新之后,在旧帐户中创建的推送证书仍能够将通知发送到您的应用程序。

From a security standpoint, it would be best for the old account to revoke its push certificate and the new account to request a new push certificate and install that on the push server. 从安全角度来看,最好是旧帐户撤销其推送证书,而新帐户则请求新的推送证书并将其安装在推送服务器上。 But from a technical point of view it is not required to do this until the old certificate is about to expire. 但是从技术角度来看,直到旧证书即将到期才需要这样做。

I have verified this to be true after transferring applications. 转移应用程序后,我已经证实这是正确的。 Last one was on january 2017. 上一个是在2017年1月。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM