Bitwarden 贡献文档
⮐ Bitwarden Contributing Documentation我的博客联系我
  • 关于
  • 入门
    • 概述
    • 工具
    • 服务器
      • 设置指南
      • 高级服务器设置
      • 数据库
        • MSSQL
        • 实体框架
      • 事件日志
      • Ingress 隧道
      • SCIM
      • 自托管指南
      • 系统管理门户
      • 单点登录 (SSO)
        • 本地 IdP
        • Okta
      • 故障排除
      • 用户机密
      • 公共 API
    • 网页客户端
      • 网页密码库
        • WebAuthn
      • 浏览器端
        • 生物识别解锁
        • Firefox 隐私模式
      • 桌面端
        • Mac App Store Dev
        • Microsoft Store
        • Native Messaging Test Runner
        • 更新测试
      • CLI
      • 故障排除
    • 移动端
      • Android
        • F-Droid
      • iOS
      • .NET MAUI (legacy)
        • Android
        • iOS
        • watchOS
    • SDK
      • 内部 SDK
      • Secrets Manager
        • Integrations
          • Kubernetes
    • 业务 App
      • 目录连接器
        • JumpCloud
        • OpenLDAP Docker 服务器
      • Key Connector
      • Splunk App
  • 贡献
    • 贡献
    • 代码样式
      • =Android & Kotlin
      • Angular & TypeScript
      • C#
      • =Rust
      • T-SQL
      • =Swift
      • Tailwind
    • 数据库迁移
      • 进化数据库设计
    • 提交签名
    • 拉取请求
      • =贡献审查程序
      • 分支
      • 代码审查
      • UI 审查 - Chromatic
    • 无障碍
    • 依赖管理
    • 功能标记
    • 模板存储库
    • 测试
      • =数据库集成测试
      • 负载测试
      • 单元测试
        • 命名约定
        • 测试结构
    • 修改用户机密
  • 架构
    • 架构
    • 架构决策记录 (ADR)
      • 0001 - Angular Reactive Forms
      • 0002 - Public API for modules
      • 0003 - Adopt Observable Data Services for Angular
      • 0004 - Refactor State Service
      • 0005 - Refactor Api Service
      • 0006 - Clients: Use Jest Mocks
      • 0007 - Manifest V3 sync Observables
      • 0008 - Server: Adopt CQRS
      • 0009 - Composition over inheritance
      • 0010 - Angular Modules
      • 0011 - Scalable Angular Clients folder structure
      • 0012 - Angular Filename convention
      • 0013 - Avoid layered folder structure for request/response models
      • 0014 - Adopt Typescript Strict flag
      • 0015 - Short Lived Browser Services
      • 0016 - Move Decryption and Encryption to Views
      • 0017 - Use Swift to build watchOS app
      • 0018 - Feature management
      • 0019 - Adoption of Web Push
      • 0020 - Observability with OpenTelemetry
      • 0021 - Logging to Standard Output
      • =0022 - Authorization
      • =0023 - Identifying Integrated Clients
    • 移动客户端架构
      • =Android
      • =iOS
        • =推送通知故障排除提示
      • =.NET MAUI (legacy)
        • =概述
        • watchOS
    • =SDK 架构
      • =数据模型
      • =依赖
      • Password Manager
        • Web
          • =互操作性
      • =Secrets Manager
      • =服务器绑定
      • =版本控制和破坏性更改
    • 网络客户端架构
      • 概述
      • 数据模型
      • 表示层
        • Angular
        • CLI
      • =依赖注入
      • 服务层
        • Vision
        • 实现
    • 服务器架构
    • 深度剖析
      • 身份验证
        • 双重身份验证
      • =授权
      • =浏览器自动填充
        • 收集页面详细信息
        • 生成并执行填充脚本
        • 表单提交检测
        • Shadow DOM
        • =内联自动填充菜单
      • Captcha
      • =只读数据库副本
      • 事件日志
      • =FIDO2 和通行密钥
        • =凭据
        • =操作
        • =命名惯例
        • =实现
          • =提供程序
            • =浏览器扩展
          • =依赖方
            • =用于解密的通行密钥
        • =术语表
      • 推送通知
        • 移动端推送通知
        • 其他客户端推送通知
      • =SSH 密钥和代理
        • =SSH 代理
      • =状态提供程序框架
        • =派生状态
    • =安全
      • =定义
      • =原则
        • =P01 - 锁定的密码库是安全的
        • =P02 - 半受损设备密码库的有限安全性
        • =P03 - 完全损坏的系统没有安全性
        • =P04 - 控制密码库数据的访问权限
        • =P05 - 将安全漏洞的影响降至最低
      • =要求
由 GitBook 提供支持
在本页
  • 背景和问题陈述​
  • 现代基础设施管理​
  • WebSockets​
  • 成本和可靠性​
  • 考虑的方案​
  • 决策结果​
  • 积极的后果​
  • 消极的后果​
  • 计划​
  1. 架构
  2. 架构决策记录 (ADR)

0019 - Adoption of Web Push

上一页0018 - Feature management下一页0020 - Observability with OpenTelemetry

最后更新于1年前

对应的

ID:
ADR-0019

状态:

进行中

发表于:

2023-02-06

背景和问题陈述​

现在,数百万用户利用推送通知进行后台密码库同步和无密码登录请求。随着平台的发展,维护当前基于 的解决方案(该解决方案使用 WebSockets)的需求也在不断增长,该系统在部署或其他应用程序更新时会给云组件带来巨大压力。加上还需要支持使用专有推送通知协议的移动设备,因此需要一种下一代混合服务来简化和扩大通知交付。

现代基础设施管理​

通知服务是一个独立部署的组件,对于 Bitwarden 托管版本而言,它由数十台虚拟机提供支持,每台虚拟机支持数以万计的并发连接。随着云中手动组件维护的减少(特别是 Kubernetes),维持与 的大量连接的负担变得复杂,预计性能会出现峰值。

WebSockets​

从表面上看,SignalR 的使用,即使是在工作负荷大得多的情况下,也运行得很好,但所执行工作的性质以及某些客户端对持久 WebSockets 连接的使用已变得十分脆弱。总的来说,通知服务的输入和输出量非常大,并且几乎全部用于面向后台的操作。各种更适合同步工作的新技术已经出现。所使用的技术或协议必须可在云中大规模使用,也能用于自托管安装。

浏览器扩展的变更和强制要求(例如 )也带来了长期后台连接的支持问题。

成本和可靠性​

新的解决方案不仅要能扩展到基本无限的连接,还要能平衡成本与用户增长,同时提供高可用性。现有的移动通知方案要么有设备限制(例如 ),要么缺乏服务级别保证。此外,某些客户端(例如 )无法利用成熟的(尽管是专有的)推送后端。单一服务提供商需要提供尽可能多的功能,同时还能为自托管提供灵活性。

考虑的方案​

关于移动通知:

  • 解决 Azure 通知中心限制 -- 由于证书安全性原因,所有移动设备(即使是自托管安装)都必须使用 Bitwarden 云进行推送,因此应设计一种解决方案,在新订阅中将设备分散到多个通知中心。

  • 采用新的移动推送通知产品 -- 使用 Azure 通知中心以外的其他没有限制的产品,或许需要牺牲一些技术。

关于协议现代化:

  • 保留 SignalR 解决方案并继续扩大其规模 -- 保留通知服务虚拟机集群,并不断扩大集群以应对规模。同时将所有移动通知转移到自定义解决方案,放弃 Azure 通知中心。

  • 采用新的组合推送服务提供商 -- 不仅要尽可能从 SignalR 迁移,还要选择支持原生移动通知协议的,与 Azure 通知中心不同的服务提供商。另外,如上所述,还要为自托管实现 Web Push 后端。

决策结果​

选择的方案:解决 Azure 通知中心限制和采用新方法处理非移动推送通知。

在研究和规划决策过程中,Azure 通知中心发布了对 Web Push 协议的支持,因此大大调整了结果。通过继续使用 Azure 通知中心,可以继续利用重要的技术投资,用户无需迁移,而重点可以放在可从 Web Push 中受益的新设备类型的规模和支持上。

积极的后果​

  • 多家服务提供商(包括 Azure 通知中心在内)都为我们的云产品提供了 Web Push 后端,而且该协议也可以在自托管的通知服务中实施。

  • Web Push 非常适合 Manifest V3 和 Service Worker。

  • 通知服务的基础设施维护负担和成本将大幅降低。

消极的后果​

  • 需要关注 Safari 对 Web Push 的支持,该支持在撰写本文时刚刚发布。

  • 使用多个 Azure 通知中心可能会增加成本。

计划​

通知服务将继续存在,并支持 SignalR 连接的 API 和 Web Push 的新 API。客户端将在可行的情况下使用 Web Push 进行连接,如果无法使用 Web Push,则使用现有的 SignalR 实现。自托管客户端将利用通知服务提供的 Web Push 和 SignalR 类似组合。Web Push 所需的密钥交换和安全性 (VAPID) 可以使用现有的内部技术用于自托管,以及服务提供商用于云托管。随着时间的推移,客户端将大部分迁移到 Web Push 连接,SignalR 的负载也将大大减少,不过在可预见的未来,SignalR 仍计划为某些客户端提供支持。

在将兼容客户端迁移到新提供商时,将考虑对推送通知有效载荷进行端到端加密(使用用户加密密钥),以便为潜在敏感的有效载荷内容提供更强的安全性。

采用新方法处理非移动推送通知 -- 在通知服务中使用 SignalR 以外的其他方法,如自研 后端。托管兼容的 Web Push 后端,供有需要的客户自行托管。将 Web Push 与 Azure 通知中心一起用于 Bitwarden 云。

Web Push 在我们需要它的大多数地方都得到了,而且是一项有价值的技术升级,便于今后的维护。

移动设备将继续使用具有原生 iOS (APNS) 和 Android (FCM) 推送通知协议的 Azure 通知中心以及 Web Push。尽管 SignalR 实现仍然可用,但对于不兼容的客户端,未来将考虑在支持 Web Push 的同时支持 (统一推送)。

官方页面地址
SignalR
Pod
Manifest V3
Azure 通知中心
F-Droid
Web Push
很好的支持
Unified Push