通过带有开发 SSL 证书的 xcode 在设备中进行推送通知测试

push notification testing in device through xcode with development SSL certificate

提问by user2268539

My app is already on the app store and with push notifications active and working (using production certificate). Now I need to add badges (before their were only alerts) in the application (already implemented on the server side). So for testing I would need a development SSL certificate. So following are my queries:

我的应用程序已经在应用程序商店中，并且推送通知处于活动状态并且可以正常工作（使用生产证书）。现在我需要在应用程序中添加徽章（之前它们只是警报）（已经在服务器端实现）。所以为了测试，我需要一个开发 SSL 证书。所以以下是我的查询：

1. Do I have to install the development SSL certificate on my server so that I can test on iPhone using development cert?
2. Will it not conflict with the already installed production SSL cert on the server.
3. Do I have to add badges in both didReceiveRemoteNotification: and didFinishLaunchingWithOptions: delegates using below code:

1. 我是否必须在我的服务器上安装开发 SSL 证书，以便我可以使用开发证书在 iPhone 上进行测试？
2. 它会不会与服务器上已经安装的生产 SSL 证书冲突。
3. 我是否必须使用以下代码在 didReceiveRemoteNotification: 和 didFinishLaunchingWithOptions: 委托中添加徽章：

code section:

代码部分：

NSString* alertValue = [[userInfo valueForKey:@"aps"] valueForKey:@"badge"];  
NSLog(@"my message-- %@",alertValue);  
int badgeValue= [alertValue intValue];  
[[UIApplication sharedApplication] setApplicationIconBadgeNumber:badgeValue];

Any suggestions?

有什么建议？

采纳答案by Rafael Kayumov

1. Yes, you should install the development SSL certificate on server. You also have to use sandbox push-notification service (gateway.sandbox.push.apple.com) with this certificate.

2. I guess they won't conflict. You should just use production SSL for AppStore app, and development SSL for test app.

3. It's better not to increment or decrement or set badge value in code. Your server should return badge value in notifications body. For example, You can't handle push when your app is not running, thus you cant change badge value in code. But if your push contains badge value, it will be set and displayed correctly any way.

1. 是的，您应该在服务器上安装开发 SSL 证书。您还必须使用带有此证书的沙盒推送通知服务 (gateway.sandbox.push.apple.com)。

2. 我想他们不会冲突。您应该只为 AppStore 应用程序使用生产 SSL，而为测试应用程序使用开发 SSL。

3. 最好不要在代码中增加或减少或设置徽章值。您的服务器应该在通知正文中返回徽章值。例如，当您的应用程序未运行时，您无法处理推送，因此您无法更改代码中的徽章值。但是如果您的推送包含徽章值，它将以任何方式正确设置和显示。

Here is the notification body example. Pass badge value for key "badge": {"aps":{"alert":"This is message.","badge":7}}

这是通知正文示例。传递关键“徽章”的徽章值：{"aps":{"alert":"This is message.","badge":7}}

By the way, didReceiveRemoteNotification: method always called when you app receives push. Even if the app is down, it will be called when you launch the app from push.

顺便说一句， didReceiveRemoteNotification: 方法总是在您的应用程序接收推送时调用。即使应用程序关闭，当您从推送启动应用程序时，它也会被调用。

回答by Bryan Musial

Just to add some additional color to the Certificate/Server/SSL questions and answers that have been proposed:

只是为已提出的证书/服务器/SSL 问题和答案添加一些额外的颜色：

Prod/Sandbox APNS Picked Based on Codesign Settings

基于 Codesign 设置选择的 Prod/Sandbox APNS

For the sake of being thorough, lets start with a quick review of the APNS environment:

为了彻底，让我们先快速回顾一下 APNS 环境：

• Applications that are Code Signed with an iOS Developmentcertificate connect to and wait for Push Notifications to be delivered from the SandboxAPNS Environment
• Applications that are Code Signed with an iOS Distributioncertificate (AppStore or Distribution > Ad-Hoc) connect to and wait for Push Notification to be delivered from the ProductionAPNS Environment.
• This setting is automatically determined by Xcode during the build process and is only configurable by selecting the type of certificate used in the CodeSign step.

• 使用iOS 开发证书进行代码签名的应用程序连接到沙盒APNS 环境并等待推送通知发送
• 使用iOS 分发证书（AppStore 或分发 > Ad-Hoc）进行代码签名的应用程序连接到生产APNS 环境并等待推送通知发送。
• 此设置在构建过程中由 Xcode 自动确定，并且只能通过选择 CodeSign 步骤中使用的证书类型进行配置。

Question 1: Do I have to install the Development SSL Certificate on my Server to Test Development Certificate Signed Apps Push Notifications?

问题 1：我是否必须在我的服务器上安装开发 SSL 证书才能测试开发证书签名的应用程序推送通知？

Yes, once and app is Code Signed, its APNS setting is sealed into the binary using the rules in the previous section. It is then up to the Developer's server code to know that the APNS token that device will generate goes with the Sandbox APNS environment and that the server should route that request for a push notification to gateway.sandbox.push.apple.com instead.

是的，一旦应用程序被代码签名，它的 APNS 设置就会使用上一节中的规则密封到二进制文件中。然后由开发人员的服务器代码知道设备将生成的 APNS 令牌与沙盒 APNS 环境相匹配，并且服务器应该将该推送通知请求路由到 gateway.sandbox.push.apple.com。

Some developers choose to setup a single server that is capable of making these distinctions while others choose to setup side-by-side instances of their servers one set to send to Production and another set to send to the Sandbox.

一些开发人员选择设置能够进行这些区分的单个服务器，而其他开发人员选择设置其服务器的并行实例，一组发送到生产，另一组发送到沙箱。

Either way, the decision resides with the individual developer and what their server-side code is capable of doing and the relative complexity of setting up a second server. Either way, users might get upset if you accidentally disabled Production push notifications while testing out upcoming features then forgot to reenable them later, so definitely be carefulwhen poking around production code!

无论哪种方式，决定权都取决于个人开发人员以及他们的服务器端代码能够做什么以及设置第二个服务器的相对复杂性。无论哪种方式，如果您在测试即将推出的功能时不小心禁用了生产推送通知，然后忘记重新启用它们，用户可能会感到不安，因此在查看生产代码时一定要小心！

Question #2: Will the Development and Production SSL Certificate Conflict?

问题 #2：开发和生产 SSL 证书会冲突吗？

From the raw SSL standpoint no they won't conflict -- you should be able to download and open/examine both of those certificates on a machine other than the server and see that the contents of the certificates are in fact different. Importing them into the same server environment (again from an SSL perspective) is perfectly allowable. To ensure they are different, when requesting the certificates make absolutely sure you create two different certificateSigningRequests and you'll inherently wind up with different data.

从原始 SSL 的角度来看，它们不会发生冲突——您应该能够在服务器以外的机器上下载和打开/检查这两个证书，并看到证书的内容实际上是不同的。将它们导入相同的服务器环境（再次从 SSL 的角度）是完全允许的。为确保它们不同，在请求证书时，请务必确保您创建两个不同的 certificateSigningRequests，并且您本质上会得到不同的数据。

From the Developer's Server-side Push Code standpoint -- It depends. See the conversation in Question 1 regarding server-side code capabilities. If the server-code was designed with this in mind then in theory the answer is also 'No they will not conflict', but that is a determination the individual developer needs to make about their own server-side code capabilities.

从开发人员的服务器端推送代码的角度来看——这取决于。请参阅问题 1 中有关服务器端代码功能的对话。如果服务器代码的设计考虑到这一点，那么理论上答案也是“不，它们不会冲突”，但这是个人开发人员需要对他们自己的服务器端代码功能做出的决定。

回答by Eran

I just wanted to add something to the existing answers. While the development cert won't conflict with the production cert installed on the same server, you might get conflicts with the device tokens stored in your DB. When you use a development cert, you get development device tokens from Apple, which are not the same as the production device tokens you'll get for your production cert. If you keep both development and production device tokens in the same database (which you probably will if you use the same server for both development and production), you will have trouble if you send notifications with development device token using the production cert or vica versa.

我只是想在现有答案中添加一些内容。虽然开发证书不会与安装在同一服务器上的生产证书发生冲突，但您可能会与存储在数据库中的设备令牌发生冲突。当您使用开发证书时，您会从 Apple 获得开发设备令牌，这与您为生产证书获得的生产设备令牌不同。如果您将开发和生产设备令牌保存在同一个数据库中（如果您将同一服务器用于开发和生产，您可能会这样做），如果您使用生产证书发送带有开发设备令牌的通知，您将遇到问题，反之亦然.

That's why it is recommended by Apple to use separate servers for development and production.

这就是为什么 Apple 建议使用单独的服务器进行开发和生产的原因。

This quote is taken from Troubleshooting Push Notifications, which is a very useful document :

这段引文来自Troubleshooting Push Notifications，这是一个非常有用的文档：

The most common problem is an invalid device token. If the token came from the sandbox environment, such as when you are testing a development build in house, you can't send it to the production push service. Each push environment will issue a different token for the same device or computer. If you do send a device token to the wrong environment, the push service will see that as an invalid token and discard the notification.

Note: It is recommended that you run a separate instance of your provider for each push environment to avoid the problem of sending device tokens to the wrong environment.

最常见的问题是无效的设备令牌。如果令牌来自沙盒环境，例如在内部测试开发构建时，则无法将其发送到生产推送服务。每个推送环境都会为同一设备或计算机发出不同的令牌。如果您确实将设备令牌发送到错误的环境，推送服务会将其视为无效令牌并丢弃通知。

注意：建议您为每个推送环境运行一个单独的提供程序实例，以避免将设备令牌发送到错误环境的问题。