我正在尝试开始在我的某个应用中实施Web Push。在我发现的示例中，客户端的端点URL通常存储在内存中，注释如下：
在制作中，您会将其存储在数据库中......
由于只有我的应用的注册用户可以/将获得推送通知，我的计划是将端点URL存储在我的数据库中用户的元数据中。到目前为止，非常好。
当我想允许同一用户在多个设备上接收通知时，问题就出现了。理论上，我将为用户订阅的每个设备添加一个新的端点到数据库。但是，在测试中，我注意到端点随着同一设备上的每个订阅/取消订阅而变化。因此，如果用户在同一设备上连续多次订阅/取消订阅，我最终会为该用户保存几个端点（除了其中一个端点都不好）。
从what I have read开始，当用户取消订阅或端点无效时，没有可靠的通知方式。那么，如何在添加新端点之前判断是否应删除旧端点？
通过重复订阅/取消订阅使用端点填充我的数据库，可以阻止用户有效地发起拒绝服务攻击？
这更像是一个笑话（我可以明显地限制给定用户的总端点），但我看到的问题是，当发送通知时，我将爆炸通知服务，其中包含数百个无效通知端点。
我希望服务器上的订阅逻辑为：
问题在于我无法弄清楚如何可靠地做＃1。
答案 0 :(得分：8)
我将为用户订阅的每个设备添加一个新的端点到数据库
最好的方法是建立一个这样的表：
endpoint | user_id
endpoint上添加一个唯一约束（或主键）：您不希望将同一浏览器关联到多个用户，因为它是一团糟（如果端点已经存在，但它有一个不同的user_id，只需更新与之关联的user_id user_id是指向您的用户表的外键如果用户在同一台设备上连续多次订阅/取消订阅，我最终会为该用户保存多个端点（除了其中一个端点都不好）。
是的，遗憾的是推送API有a wild unsubscription mechanism，您必须处理它。
端点可能过期或可能无效（甚至是恶意的，如android.chromlum.info）。当您尝试从应用程序服务器发送推送消息时，需要检测故障（使用HTTP状态代码，超时等）。然后，对于某种类型的故障（永久性故障，如过期），您需要删除端点。
通过重复订阅/取消订阅使用端点填充我的数据库，可以阻止用户有效地发起拒绝服务攻击？
如上所述，一旦您意识到它们已过期或无效，您需要正确删除无效端点。基本上他们最多会产生一个无效请求。此外，如果您具有高吞吐量，则服务器只需几秒钟就可以请求数千个端点。
我的建议是基于我在开发Pushpad时进行的大量实验和思考。