反向推送器 - 需要接收而不是发送的秘密

Question

Pusher 服务的工作原理如下图所示：

反向使用（和切换数据通道）是否有意义？我的用例如下：

• 最终用户（实际上是移动设备，而不是浏览器）通过基于 HTTP 的 REST API 向 Pusher 发送消息
• 我的防火墙机器通过 WebSockets API 连接到 Pusher，订阅频道并实时接收消息

这样我可以使用沙盒计划（仅使用 1 个持久连接），但移动应用程序必须包含 Puser 应用程序密钥。

据我了解，任何人都可以使用此密钥通过 websockets 注册订阅相同的消息流。是否有反向模式，接收消息需要知道秘密？也许其他服务更适合？

Answer 1

更安全的解决方案是让移动客户端使用client events。客户端事件只能在private channels 上触发，其中必须对频道的订阅进行身份验证。身份验证请求应该到达您控制的 HTTP 端点，以便您可以验证订阅请求。

您的防火墙机器可以拥有一个 WebSocket 连接并通过该连接接收客户端事件。或者它可以通过client event WebHooks 接收客户端事件，如果它暴露了一个 HTTP 端点。