了解如何存储 Web 推送端点

Question

我正在尝试开始在我的一个应用中实现Web Push。在我找到的示例中，客户端的端点 URL 通常存储在内存中，并带有如下注释：

在生产中，您可以将其存储在数据库中...

由于只有我的应用程序的注册用户可以/将收到推送通知，我的计划是将端点 URL 存储在我的数据库中的用户元数据中。到目前为止，一切顺利。

当我想允许同一个用户在多个设备上接收通知时，问题就出现了。理论上，我将为用户订阅的每台设备在数据库中添加一个新端点。但是，在测试中，我注意到端点会随着同一设备上的每个订阅/取消订阅而变化。因此，如果用户在同一设备上连续多次订阅/取消订阅，我最终会为该用户保存多个端点（除了一个之外，所有端点都是坏的）。

从what I have read 开始，当用户取消订阅或端点以其他方式无效时，没有可靠的方法来通知。那么，如何判断是否应该在添加新端点之前删除旧端点？

如何阻止用户通过重复订阅/取消订阅在我的数据库中填充端点来有效地发起拒绝服务攻击？

这更像是一个玩笑（我可以明显地限制给定用户的总端点），但我看到的问题是，当需要发送通知时，我会向通知服务发送数百个无效通知端点。

---

我希望我的服务器上的订阅逻辑是：

1. 检查我们是否已经为此用户/设备组合保存了端点
2. 如果不添加，如果是，更新它

问题是我无法弄清楚如何可靠地执行 #1。

Answer 1

我将为用户订阅的每台设备在数据库中添加一个新端点

最好的办法是有一个这样的表：

endpoint | user_id

• 在endpoint 上添加唯一约束（或主键）：您不想将同一个浏览器关联到多个用户，因为它是一团糟（如果端点已经存在但它有不同的@ 987654327@，只需更新与之关联的user_id）
• user_id 是指向用户表的外键

如果用户在同一设备上连续多次订阅/取消订阅，我最终会为该用户保存多个端点（除了一个之外，所有端点都是坏的）。

是的，不幸的是推送 API 有 a wild unsubscription mechanism，你必须处理它。

端点可能过期或无效（甚至是恶意的，例如android.chromlum.info）。当您尝试从应用服务器发送推送消息时，您需要检测失败（使用 HTTP 状态代码、超时等）。然后，对于某种故障（永久故障，如过期），您需要删除端点。

如何阻止用户通过重复订阅/取消订阅在我的数据库中填充端点来有效地发起拒绝服务攻击？

如上所述，一旦您意识到无效端点已过期或无效，您需要正确删除它们。基本上他们最多会产生一个无效请求。此外，如果您的吞吐量很高，您的服务器只需几秒钟即可向数千个端点发出请求。

我的建议基于我在开发Pushpad 时所做的大量实验和思考。