Bitwarden 本地 Reverse Proxy Emulator 如何模拟 ELB Cookie 门禁并接入开发客户端【免费下载链接】clientsBitwarden client apps (web, browser extension, desktop, and cli).项目地址: https://gitcode.com/GitHub_Trending/cl/clientsBitwarden clients 仓库中内置了一个本地开发工具Reverse Proxy Emulator位于scripts/reverse-proxy-emulator/它不依赖任何真实的 AWS 基础设施就能模拟 AWS ELB 的认证门禁所有流量都必须携带BitwardenLoadBalancerCookie才能到达后端没有该 Cookie 的请求会被重定向到一个内置的认证页面。当你需要测试客户端在经过负载均衡门禁环境下的认证、重认证流程时可以在本地把它跑起来再把桌面端、浏览器扩展或 Web Vault 客户端的服务器地址指向它即可。工作原理哪些请求被放行哪些被拦截根据 README 与脚本源码 index.ts代理的门禁逻辑分三类Bypass 路径/api/config和/api/cookie-vendor无条件转发到后端因为客户端在认证之前就需要访问这两个接口。带 Cookie 的请求请求头中携带了正确 Cookie 值的请求会被代理到后端。不带 Cookie 的请求被重定向到/_elb-auth该页面展示一个 Continue 按钮点击后在浏览器中写入 Cookie 并跳回原 URL。此外SignalR 通知 Hub 使用的 WebSocket 连接同样受 Cookie 门禁约束没有 Cookie 的 WebSocket 升级请求会被直接断开有 Cookie 的则透传代理。准备条件启动代理前需要满足以下条件Node 22.12。README 明确说明要求 Node 22.12 及以上版本因为运行脚本使用--experimental-strip-types标志该标志从 Node 22.12 起稳定。仓库根目录 package.json 中的脚本定义如下dev:reverse-proxy: node --experimental-strip-types scripts/reverse-proxy-emulator/index.ts一个可访问的后端服务。默认后端地址是https://localhost:8080即 Web Vault 开发服务器的默认端口见 webpack.base.js 中envConfig.dev?.port ?? 8080的配置。你也可以通过--backend指向远程后端例如https://vault.bitwarden.com。受信任的 TLS 证书。代理使用与 Web Vault 开发服务器相同的证书优先使用apps/web/dev-server.local.pem开发者本地覆盖否则使用仓库内置的 apps/web/dev-server.shared.pem选择逻辑与 webpack.base.js 中 Web Vault 的 dev server 配置一致。该证书必须是单个 PEM 文件同时包含 key 和 cert。如果证书还没有被操作系统或浏览器信任在 macOS 上打开Keychain Access找到localhost证书双击展开Trust把When using this certificate设为Always Trust。如果你已经为 Web Vault 开发服务器信任过该证书则无需额外操作。启动代理在仓库根目录执行npm run dev:reverse-proxy启动后脚本源码中定义的启动日志会打印当前配置以下为按源码 index.ts 整理的示例输出Reverse Proxy Emulator started Listening: https://localhost:8000 Backend: https://localhost:8080 Cookie name: BitwardenLoadBalancerCookie Cookie TTL: 86400s Insecure TLS: false Bypass paths: /api/config, /api/cookie-vendor Press R to rotate the cookie and force re-authentication.看到Listening行确认端口Backend行确认代理目标即可进入下一步。接入开发客户端把 Bitwarden 客户端桌面端、浏览器扩展或 Web Vault的自定义服务器 URL 设置为https://localhost:8000如果改了端口用你实际配置的端口。之后客户端会像面对真实的负载均衡环境一样通过代理与后端通信首次请求因缺少BitwardenLoadBalancerCookie被重定向到/_elb-auth页面点击Continue写入 Cookie 并跳回原地址后续请求即可携带 Cookie 直通后端。常用配置项所有选项都可以通过环境变量或 CLI 参数设置CLI 参数优先来源README 的 Configuration 一节CLI 参数环境变量默认值--portRPE_PORT8000--backendRPE_BACKEND_URLhttps://localhost:8080--cookie-nameRPE_COOKIE_NAMEBitwardenLoadBalancerCookie--cookie-max-ageRPE_COOKIE_MAX_AGE8640024 小时单位秒--insecure仅 flagfalseREADME 给出的两个示例命令指向远程后端npm run dev:reverse-proxy -- --backend https://vault.bitwarden.com使用不同端口和 Cookie 有效期通过环境变量RPE_PORT9000 RPE_COOKIE_MAX_AGE3600 npm run dev:reverse-proxy验证与 Cookie 轮换验证是否按预期工作可以按源码中的行为对照检查访问https://localhost:8000下任意非 bypass 路径未带 Cookie 时应看到 302 重定向到/_elb-auth?return_to...页面出现 Authentication Required 标题和Continue按钮。点击Continue后浏览器写入BitwardenLoadBalancerCookie并跳回原 URL再次请求应正常到达后端。直接请求/api/config或/api/cookie-vendor应无需 Cookie 即被转发到后端。在代理运行期间按R键可以轮换 Cookiecookie generation 自增强制所有客户端在下一次请求时重新走/_elb-auth认证流程。README 说明这对测试重认证流程、不必等待 Cookie TTL 过期很有用。轮换成功后终端会打印Cookie rotated to generation N日志。常见问题端口冲突如果 8000 端口已被占用用--port或RPE_PORT更换端口同时记得同步修改客户端的服务器 URL。后端连接失败代理在转发失败时会输出带具体原因的日志见 index.ts 的describeProxyError例如后端未启动时打印Could not connect to backend at ... Check that the server is running.主机名无法解析时提示检查--backendURL。后端 TLS 证书错误后端是公共地址如vault.bitwarden.com时按系统 CA 链正常验证如果后端使用不在信任库中的自签名证书启动时加--insecure跳过对后端的 TLS 校验。注意 README 明确提示该选项未充分测试在某些情况下可能不生效。代理自身对后端的默认校验会把本地自签名 cert 扩展进系统 CA 包因此本地开发服务器与公共后端可以共用同一代理。限制该工具只在 Node 22.12 环境可用且仓库根目录必须存在apps/web/dev-server.shared.pem或开发者自建的apps/web/dev-server.local.pem否则脚本会直接报 No TLS certificate found 错误退出。客户端必须能信任代理使用的 TLS 证书否则浏览器/客户端会在 HTTPS 层就拦截请求门禁流程根本不会开始。【免费下载链接】clientsBitwarden client apps (web, browser extension, desktop, and cli).项目地址: https://gitcode.com/GitHub_Trending/cl/clients创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Bitwarden 本地 Reverse Proxy Emulator 如何模拟 ELB Cookie 门禁并接入开发客户端
Bitwarden 本地 Reverse Proxy Emulator 如何模拟 ELB Cookie 门禁并接入开发客户端【免费下载链接】clientsBitwarden client apps (web, browser extension, desktop, and cli).项目地址: https://gitcode.com/GitHub_Trending/cl/clientsBitwarden clients 仓库中内置了一个本地开发工具Reverse Proxy Emulator位于scripts/reverse-proxy-emulator/它不依赖任何真实的 AWS 基础设施就能模拟 AWS ELB 的认证门禁所有流量都必须携带BitwardenLoadBalancerCookie才能到达后端没有该 Cookie 的请求会被重定向到一个内置的认证页面。当你需要测试客户端在经过负载均衡门禁环境下的认证、重认证流程时可以在本地把它跑起来再把桌面端、浏览器扩展或 Web Vault 客户端的服务器地址指向它即可。工作原理哪些请求被放行哪些被拦截根据 README 与脚本源码 index.ts代理的门禁逻辑分三类Bypass 路径/api/config和/api/cookie-vendor无条件转发到后端因为客户端在认证之前就需要访问这两个接口。带 Cookie 的请求请求头中携带了正确 Cookie 值的请求会被代理到后端。不带 Cookie 的请求被重定向到/_elb-auth该页面展示一个 Continue 按钮点击后在浏览器中写入 Cookie 并跳回原 URL。此外SignalR 通知 Hub 使用的 WebSocket 连接同样受 Cookie 门禁约束没有 Cookie 的 WebSocket 升级请求会被直接断开有 Cookie 的则透传代理。准备条件启动代理前需要满足以下条件Node 22.12。README 明确说明要求 Node 22.12 及以上版本因为运行脚本使用--experimental-strip-types标志该标志从 Node 22.12 起稳定。仓库根目录 package.json 中的脚本定义如下dev:reverse-proxy: node --experimental-strip-types scripts/reverse-proxy-emulator/index.ts一个可访问的后端服务。默认后端地址是https://localhost:8080即 Web Vault 开发服务器的默认端口见 webpack.base.js 中envConfig.dev?.port ?? 8080的配置。你也可以通过--backend指向远程后端例如https://vault.bitwarden.com。受信任的 TLS 证书。代理使用与 Web Vault 开发服务器相同的证书优先使用apps/web/dev-server.local.pem开发者本地覆盖否则使用仓库内置的 apps/web/dev-server.shared.pem选择逻辑与 webpack.base.js 中 Web Vault 的 dev server 配置一致。该证书必须是单个 PEM 文件同时包含 key 和 cert。如果证书还没有被操作系统或浏览器信任在 macOS 上打开Keychain Access找到localhost证书双击展开Trust把When using this certificate设为Always Trust。如果你已经为 Web Vault 开发服务器信任过该证书则无需额外操作。启动代理在仓库根目录执行npm run dev:reverse-proxy启动后脚本源码中定义的启动日志会打印当前配置以下为按源码 index.ts 整理的示例输出Reverse Proxy Emulator started Listening: https://localhost:8000 Backend: https://localhost:8080 Cookie name: BitwardenLoadBalancerCookie Cookie TTL: 86400s Insecure TLS: false Bypass paths: /api/config, /api/cookie-vendor Press R to rotate the cookie and force re-authentication.看到Listening行确认端口Backend行确认代理目标即可进入下一步。接入开发客户端把 Bitwarden 客户端桌面端、浏览器扩展或 Web Vault的自定义服务器 URL 设置为https://localhost:8000如果改了端口用你实际配置的端口。之后客户端会像面对真实的负载均衡环境一样通过代理与后端通信首次请求因缺少BitwardenLoadBalancerCookie被重定向到/_elb-auth页面点击Continue写入 Cookie 并跳回原地址后续请求即可携带 Cookie 直通后端。常用配置项所有选项都可以通过环境变量或 CLI 参数设置CLI 参数优先来源README 的 Configuration 一节CLI 参数环境变量默认值--portRPE_PORT8000--backendRPE_BACKEND_URLhttps://localhost:8080--cookie-nameRPE_COOKIE_NAMEBitwardenLoadBalancerCookie--cookie-max-ageRPE_COOKIE_MAX_AGE8640024 小时单位秒--insecure仅 flagfalseREADME 给出的两个示例命令指向远程后端npm run dev:reverse-proxy -- --backend https://vault.bitwarden.com使用不同端口和 Cookie 有效期通过环境变量RPE_PORT9000 RPE_COOKIE_MAX_AGE3600 npm run dev:reverse-proxy验证与 Cookie 轮换验证是否按预期工作可以按源码中的行为对照检查访问https://localhost:8000下任意非 bypass 路径未带 Cookie 时应看到 302 重定向到/_elb-auth?return_to...页面出现 Authentication Required 标题和Continue按钮。点击Continue后浏览器写入BitwardenLoadBalancerCookie并跳回原 URL再次请求应正常到达后端。直接请求/api/config或/api/cookie-vendor应无需 Cookie 即被转发到后端。在代理运行期间按R键可以轮换 Cookiecookie generation 自增强制所有客户端在下一次请求时重新走/_elb-auth认证流程。README 说明这对测试重认证流程、不必等待 Cookie TTL 过期很有用。轮换成功后终端会打印Cookie rotated to generation N日志。常见问题端口冲突如果 8000 端口已被占用用--port或RPE_PORT更换端口同时记得同步修改客户端的服务器 URL。后端连接失败代理在转发失败时会输出带具体原因的日志见 index.ts 的describeProxyError例如后端未启动时打印Could not connect to backend at ... Check that the server is running.主机名无法解析时提示检查--backendURL。后端 TLS 证书错误后端是公共地址如vault.bitwarden.com时按系统 CA 链正常验证如果后端使用不在信任库中的自签名证书启动时加--insecure跳过对后端的 TLS 校验。注意 README 明确提示该选项未充分测试在某些情况下可能不生效。代理自身对后端的默认校验会把本地自签名 cert 扩展进系统 CA 包因此本地开发服务器与公共后端可以共用同一代理。限制该工具只在 Node 22.12 环境可用且仓库根目录必须存在apps/web/dev-server.shared.pem或开发者自建的apps/web/dev-server.local.pem否则脚本会直接报 No TLS certificate found 错误退出。客户端必须能信任代理使用的 TLS 证书否则浏览器/客户端会在 HTTPS 层就拦截请求门禁流程根本不会开始。【免费下载链接】clientsBitwarden client apps (web, browser extension, desktop, and cli).项目地址: https://gitcode.com/GitHub_Trending/cl/clients创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考