微软软件推送服务器地址,Windows 推送通知服务 (WNS) 概述

Windows 推送通知服务 (WNS) 概述

09/28/2020

本文内容

Windows 推送 Notification Services (WNS) 使第三方开发人员能够从他们自己的云服务发送 toast、磁贴、徽章和原始更新。 这提供了一种高效而可靠地向用户提供新更新的机制。

工作原理

下图显示了用于发送推送通知的完整数据流。 它涉及到以下步骤：

您的应用程序从 WNS 请求推送通知通道。

Windows 要求 WNS 创建通知通道。 此通道以统一资源标识符 (URI) 的形式返回到调用设备。

WNS 向应用返回通知通道 URI。

你的应用将 URI 发送到你自己的云服务。 然后你将 URI 存储在自己的云服务上，以便在发生通知时访问该 URI。 URI 是你自己的应用与自己的服务之间的接口；它负责通过安全可靠的 Web 标准来实现此接口。

当你的云服务有要发送的更新时，它使用通道 URI 通知 WNS。 通过安全套接字层 (SSL) 发送 TTP POST 请求(包括通知负载)来执行此操作。 此步骤需要身份验证。

WNS 接收请求，并将通知路由到相应的设备。

注册你的应用，并为你的云服务接收凭据

必须先向应用商店仪表板注册应用，然后才能使用 WNS 发送通知，如 此处所述。

请求通知通道

当能够接收推送通知的应用运行时，它必须首先通过 CreatePushNotificationChannelForApplicationAsync 请求通知通道。 若要查看全面介绍和示例代码，请参阅如何请求、创建和保存通知通道。 此 API 会返回一个唯一链接到进行调用的应用程序及其磁贴的通道 URI，所有通知类型均可通过此 URI 发送。

应用成功创建了通道 URI 之后，会将其与任何应该与该 URI 关联的特定于应用的元数据一起发送到它的云服务。

重要事项

我们不保证应用的通知通道 URI 将始终保持相同。 我们建议应用在每次运行时均请求一个新的通道，并在 URI 更改时更新其服务。 开发人员绝不能修改该通道 URI，而应将其视作一段黑盒字符串。 此时，通道 URI 于 30 天后过期。 如果 Windows 10 应用会在后台定期更新其通道，则可以下载针对 Windows 8.1 的推送和定期通知示例、重新使用其源代码和/或其展示的模式。

云服务和客户端应用之间的接口由你这个开发人员来实现。 我们建议应用使用其自身的服务完成身份验证过程，并通过安全的协议(如 HTTPS)来传输数据。

云服务必须始终确保通道 URI 使用域“notify.windows.com”。 该服务永远不应向任何其他域中的通道推送通知。 如果应用的回调发生了泄露，恶意攻击者可能会将该通道 URI 提交给假冒 WNS。 如果不检查域，云服务可能会在不知情的情况下向此攻击者泄露信息。

如果你的云服务尝试将通知传递到过期通道，WNS 将返回响应代码 410。 为响应此代码，你的服务不应再尝试将通知发送到该 URI。

验证你的云服务

若要发送通知，云服务必须通过 WNS 进行验证。 此过程的第一步出现在使用 Microsoft Store 仪表板注册应用之时。 在注册过程中，应用会获得一个程序包安全标识符 (SID) 和一个密钥。 该信息由你的云服务用于向 WNS 进行验证。

WNS 身份验证方案通过来自 OAuth 2.0 协议的客户端凭据配置文件来实现。 云服务通过提供其凭据(程序包 SID 和密钥)来向 WNS 进行验证。 反过来，云服务会获得一个访问令牌。 该访问令牌允许云服务发送通知。 每次向 WNS 发送通知请求时都必须使用该令牌。

该信息链简述如下：

云服务遵循 OAuth 2.0 协议通过 HTTPS 将其凭据发送给 WNS。 这会向 WNS 验证该服务。

如果身份验证成功，则 WNS 会返回一个访问令牌。 此访问令牌在所有后续通知请求中使用，直到令牌过期。