Web推送订阅归属（设备/浏览器）及同设备多用户免重复授权方案咨询

一、Subscription到底对应什么？ #

每个subscription是浏览器实例+设备+当前站点的唯一凭证，简单来说：

• 同一设备上的同一浏览器（比如Chrome）访问你的站点，只会生成一个有效的subscription（除非用户清除站点数据、重置通知权限或浏览器版本更新导致订阅失效）。
• 它不直接关联你的用户账号，只是浏览器给站点的推送授权凭证——谁持有这个凭证，就能给这个浏览器实例推送通知。

你遇到的问题根源就在这：用户A登录时生成的订阅，绑定了A的用户ID；当用户B用同一浏览器登录时，浏览器已经授权过通知权限，不会再弹窗请求，而后端还是把这个订阅和A绑定，所以推送时B会收到A的通知。

二、无需登出取消订阅、也不用每次登录请求权限的处理方案 #

核心思路是让订阅和当前登录用户动态绑定，而非固定绑定第一次创建订阅的用户，具体步骤如下：

前端处理逻辑 #

1. 用户登录成功后，先尝试获取已存在的订阅：

   // 注册service worker后，获取现有订阅
   const registration = await navigator.serviceWorker.ready;
   const existingSubscription = await registration.pushManager.getSubscription();
   

2. 如果有现有订阅：
   • 直接把当前登录用户ID和这个订阅一起发给后端，请求更新绑定关系。
3. 如果没有现有订阅：
   • 再请求通知权限，授权后生成新订阅，然后发给后端和当前用户ID绑定。

后端处理逻辑（NestJS） #

1. 接收前端传来的userId和subscription：
   • 先查询数据库，找到这个subscription.endpoint对应的所有旧绑定记录（一个订阅可能绑定过旧用户）。
   • 删除这些旧绑定记录，避免旧用户的通知推送到当前设备。
   • 插入/更新新的绑定记录：把当前userId和subscription关联存储。
2. 推送通知时，只根据目标用户ID查询其绑定的所有有效订阅，进行推送。
3. 处理推送失败：
   • 使用web-push推送时，监听失败响应（比如HTTP 410状态码，说明订阅已失效），及时从数据库删除该订阅的绑定记录，避免无效推送。

额外优化 #

• 前端可把当前用户ID存在localStorage，下次登录时先对比localStorage的用户ID和当前登录用户ID，若不一致则主动触发订阅绑定更新逻辑。
• 后端可定期清理失效的订阅记录（比如通过定时任务批量验证订阅有效性）。

内容的提问来源于stack exchange，提问作者twennyfouwr