使用pu.sh从命令行发送iOS推送通知
我一段时间以来一直在大多数应用程序中使用推送通知。 在iOS上,它们是远程通知功能的核心。 它们快速,安全并减少了开发人员为有效地向其应用程序和用户传播信息所需的工作量。
此外,这些天您可以在其中显示丰富而全面的内容。 我在这里写了一篇有关该文章的文章,您会发现它对您自己的应用程序开发很有用,您可能会喜欢阅读。
因此,尽管我对这项技术感到满意,但在某个领域中,我一直发现自己想要并且正在测试它们。 通过这种方式,我的意思是能够多次将它们发送到安装有我的应用程序的特定设备上,并且可以重复多次进行,以便我可以测试,调整和重写其文本和有效负载。
在iOS上测试推送通知
通常,您可能有自己的服务器设置,或者可能使用了许多现有的推送通知服务之一。 所有这些都需要大量时间和精力来启动和运行。 理想情况下,您可能想开始仅使用Mac,iOS设备和零现金(当然不包括为Mac和设备支付的钱)发送通知。
如果您在线上进行了一些研究,您可能会遇到NWPusher,它虽然效果很好,但仅适用于直接从钥匙串读取的证书和密钥的基于证书的身份验证。 它还作为您需要安装的Mac应用程序分发,因此它只能在该平台上运行。 您还需要每年自己生成这些证书,并且每次都是一个多步骤过程。
Shell脚本解决方案
我使用基于令牌的通知,而不是基于证书的通知,它更易于设置和管理。 另外,我没有创建一个用于发送通知的图形应用程序,而是编写了一个bash shell脚本来发送通知。 它称为pu.sh
,位于GitHub上,此处也有完整记录。 同时,您也可以在下面与我联系,以获取更全面的演练。
我还要指出的是,使用Shell脚本解决方案可以确保透明度。 您已经预先确切知道该脚本对您提供的信息有什么作用,即该脚本仅将有效负载发送到APNs服务器。
收集所有先决条件
以下两节是此处官方文档中信息的精简版本。 对于我们的解决方案,我们将使用基于令牌的推送通知,而不是基于证书的推送通知。
基于令牌的APN连接
基于令牌的身份验证比基于证书的通信速度更快,因为它不需要APN来查找与服务器相关的证书。 您可以将同一令牌用于多个提供商服务器,并且您所有公司的应用程序都可以使用一个令牌。 请记住,您必须每小时至少使用签名密钥更新一次令牌。 我们将尽快介绍如何更新您的令牌。 令牌还可以持续任意长的时间。 直到您将其吊销为止,否则每年都必须重新发行和重新分发证书。
获取加密密钥和密钥ID
您需要一个APNs身份验证令牌签名密钥来生成服务器使用的令牌,以便发送推送通知。 您可以从开发人员帐户developer.apple.com上的“ 密钥 ➙ 所有”部分中请求此密钥,如下所示。
继续下一步之后,您将获得:
- 密钥ID为的10个字符的字符串 。 随时准备使用它。 如果您忘记了它,它仍然可以在开发人员门户中使用。
-
.p8
文本文件的 签名密钥 。 将此放置在安全的地方。 例如,不要将其保存在源代码存储库中。 如果丢失,它将永远消失,您将不得不撤销它并重新生成它。 如果此密钥以任何方式受到破坏,则可以将其用于向应用程序发送推送通知-因此,如果您怀疑发生了这种情况,请将其撤消并请求一个新密钥。
您已经知道此过程比创建密钥,证书等要简单得多。
获取设备令牌
以下是您的应用程序应用程序委托的方法,带有一些简短的解释性注释,您需要获取设备令牌。
您可能已经注意到,上面的代码中我们并没有征求用户的许可。 在本文中,我们将通过在通知有效负载中将content-available
键设置为1
来使用静默通知。 但是对于您自己的实现,您当然可以省略此标志,并要求用户许可向其发送推送通知。 现在,您可以自由发送所需的任何类型的有效载荷。 这里有很多信息可以为您提供帮助。
让我们创建和加密令牌
安装OpenSSL
如果您已经安装了OpenSSL,则可以跳到下一部分。
为了生成令牌,我们需要在计算机上安装OpenSSL。 如果您使用的是Mac(如果您正在构建iOS应用程序),请执行以下操作:
- 打开一个终端
- 安装自制程序:
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
- 键入
brew install openssl
做完了!
生成令牌
以下是生成令牌的bash脚本。 您将必须提供您的团队ID(在开发人员帐户中找到),密钥ID(在我们之前创建密钥的部分中找到)和您在上一步中创建的p8文件,并且已保存在安全的地方。
要执行该脚本,请将其放置在.sh
文件(例如script.sh)中,并在脚本所在目录的终端中键入./script.sh
。
您的输出将类似于以下内容(由两个点连接的三个字符串):
eyAiYWxnFCIiB9.eyAiaXNz1OTMwOCB9.MEUCIQDRXq8MwIQP5zeSnpwlQ
这是一个JSON Web令牌或简称JWT。 您可以在https://jwt.io/上找到有关它们的更多信息,以及大量的多种语言的签名和验证库。
将推送通知发送到设备
现在,我们拥有发送推送通知所需的一切; 那是一个签名的令牌和一个设备标识符。 在下面的脚本中,您只需提供应用程序的捆绑包ID和您先前从Xcode控制台获取的设备令牌。
注意:开发与生产
将上面的ENDPOINT
文本替换为脚本顶部注释掉部分中的相应URL。 将应用程序直接从Xcode运行到设备上时使用开发,在其他情况下(分别用于Testflight,Adhoc,Enterprise或Appstore)进行生产。
接收推送通知
如果您插入或无线连接到Xcode的物理设备(不是模拟器,则推送通知在模拟器中不起作用),运行此脚本将向该设备发送通知。 您可以在下面进行验证:
您刚收到推送通知🚀
注意:丰富的推送通知
要发送丰富的推送通知,请导入UserNotifications
框架,并在AppDelegate.swift中添加UNUserNotificationCenterDelegate
。 然后在didFinishLaunchingWithOptions
添加此内容。
您可以让上述脚本中的--data
包含此有效负载(作为一行上的字符串):
{
"aps": {
"alert": {
"body": "Push notification body",
"title": "Push notification title"
},
"mutable-content": 1,
category: "rich-apns"
},
"media-url": "},
https://i.imgur.com/t4WGJQx.jpg
"media-url": ""
}"
}
如果您想进一步了解如何撰写和发送丰富的推送通知,请点击此处阅读我的文章。
故障排除
不幸的是,当出现问题时,从APNS返回的反馈令人非常不满意。 这些是可能返回的状态代码,它们显示在上一个脚本的输出中。
200:成功
400:错误的请求
403:证书或提供者身份验证令牌出错
405:请求使用了错误的:method
值。 仅支持POST
请求。
410:设备令牌对该主题不再有效。
413:通知有效载荷太大。
429:服务器收到的对同一设备令牌的请求过多。
500内部服务器错误
503:服务器正在关闭且不可用。
如果状态码为200
一切正常,您已收到推送通知。
通常,您应始终使用最新的设备令牌,该设备令牌实际上应来自您要发送到的设备,并且应确保正确拼写了团队ID,密钥ID和捆绑软件ID。
对于成功的请求,响应的主体为空。 失败时,响应主体包含带有reason
键的JSON字典,该键可让您大致了解出了什么问题,例如BadDeviceToken.
离别的想法
我希望您发现此解决方案对您的推送通知测试有所帮助。 我也希望您发现此处包含的信息对于您自己的应用程序开发足够有价值。
谢谢❤️