push-notification - 了解如何存储 Web 推送端点

Question

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

In production you would store this in your database...

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

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

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

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

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

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

检查我们是否已经为此用户/设备组合保存了端点

如果没有添加，如果有，更新它

问题是我不知道如何可靠地做#1。

Answer 1

I will just add a new endpoint to the database for each device the user subscribes with

最好的方法是有一个这样的表:

endpoint | user_id

在 endpoint 上添加唯一约束(或主键) :您不想将同一个浏览器与多个用户相关联，因为它很困惑(如果端点已经存在但它具有不同的 user_id ，只需更新与之关联的 user_id)

user_id是指向您的用户表的外键

if a user subscribes/unsubscribes several times in a row on the same device, I wind up with several endpoints saved for that user (all but one of which are bad).

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

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

What's to stop a user from effectively mounting a denial of service attack by filling my db with endpoints through repeated subscription/unsubscription?

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

我的建议是基于我在开发过程中所做的大量实验和思考 Pushpad .