L6-39：浏览器身份配置 —— 让AI以你的身份登录任何网站

🎯 学 gstack 的浏览器认证配置：让无头浏览器能携带真实的登录 Cookie，访问需要认证的页面——从"手动在浏览器里操作"变成"自动化访问你的 SaaS 工具、后台系统和分析平台"。 ⏱️ 预计时间：15 分钟

💡 新手提示：Cookie 配置就像"把你的门禁卡复制给 AI 用"。它让 AI 可以以你的身份访问需要登录的网站，但要小心——不要共享支付或银行类网站的凭证，建议使用专用的自动化账号。

---

§1 课程概览

[!note]- 白话小课堂 把 Cookie 想象成你的门禁卡——setup-browser-cookies 就是把你的门禁卡复制一份给 AI 用。这样无头浏览器也能以你的身份登录网站了，不需要每次手动输入密码。

两条铁律刻在脑门上：①不要共享支付或银行类网站的 Cookie——即使只是 Cookie 不是密码，获取 Cookie 的人也能在有效期内冒充你进行交易；②用专用的自动化账号，别拿自己的主账号冒险——万一脚本出 bug 误操作，影响的是自动化账号而不是你真正的数据。

Cookie 过期后 AI 会静默失败——看起来页面加载了但实际上显示的是登录页。所以 一定要做内容验证，别让"看起来在工作其实已断线"的状态持续一周。

---

[!quote]- 📖 原Skill精要 技能名称：setup-browser-cookies 核心功能：从真实 Chromium 浏览器导入 Cookie 到无头 browse 会话。打开交互式选择器 UI，选择要导入的 Cookie 域名。在 QA 测试需要认证的页面之前使用。让无头浏览器携带真实登录状态访问 SaaS 工具、后台系统和分析平台。 所属体系：gstack 虚拟工程团队 协作关系：配置完成后 [[L6-20-自动化测试修复|qa]] 和 [[L6-37-浏览器自动化|browse]] 可访问需要认证的页面

§2 Cookie 配置解决什么问题？

---

§3 安全考量

---

结构拆解

---

§4 电商 Skill 案例：电商管理后台多环境Cookie配置自动化

🛒 实战案例：某电商SaaS平台的运营团队需要访问3套环境的管理后台——生产环境(admin.mega-shop.com)、预发环境(admin-staging.mega-shop.com)、开发环境(admin-dev.mega-shop.com)。每套环境需要独立登录，每次切换环境都要重新输入账号密码。使用setup-browser-cookies为这3套环境配置持久化登录态。

• 配置流程：/setup-browser-cookies admin.mega-shop.com→打开Chrome→导航到admin.mega-shop.com→手动输入运营专用账号密码登录→Cookie自动提取并保存到~/.gstack/cookies/admin.mega-shop.com.json(0600权限)→重复配置admin-staging和admin-dev。配置完成后$B goto https://admin.mega-shop.com/orders自动注入保存的Cookie携带登录态，不需要每次输入密码。
• 安全措施：使用专用运营自动化账号（仅授予"查看订单+导出报表"权限，无退款/改价权限）→隔离风险：即使Cookie文件泄露，攻击者在Cookie有效期内也只能查看订单数据而不能执行资金操作。Cookie存储文件权限0600（仅文件所有者可读写），定期轮换（过期前7天提醒重新配置），不在CI环境中使用。
• 应用效果：日常自动化任务——$B goto https://admin.mega-shop.com/orders/pending查看待处理订单截图、$B goto https://admin-staging.mega-shop.com/health预发环境健康检查、$B goto https://admin-dev.mega-shop.com/config验证新功能配置。Cookie过期检测——$B goto后检查auth_status（AUTHENTICATED/EXPIRED/UNKNOWN），若EXPIRED则主动告警"Cookie已过期请重新配置"，避免静默失败（用户以为自动化在工作，实际Cookie已过期一周）。

🔑 启示：无头浏览器的"认证困境"是所有浏览器自动化项目的第一个坑——每次都是全新session，无法访问需要登录的页面。setup-browser-cookies通过"手动登录一次→提取Cookie→后续自动注入"的模式解决了这个问题，但它引入了对等的安全风险——Cookie文件就是登录凭证。专用账号+最小权限+定期轮换是降低这个风险的三个支柱。

[!info] 参考来源 Cookie 安全存储参考了 Chrome Cookie Security 和 OWASP（OWASP：开放Web应用安全项目）的 Session Management Cheat Sheet。

§5 掌握检验

Q1：无头浏览器的"认证困境"是什么？setup-browser-cookies 如何解决这个问题？

• A) 无头浏览器无法打开 HTTPS 网站——Cookie 注入添加 SSL 支持
• B) 无头浏览器每次都是全新 session（没有登录状态），无法访问需要认证的页面——从真实浏览器提取 Cookie 并注入到无头浏览器，使其携带登录状态
• C) 无头浏览器运行太慢——Cookie 注入提升速度
• D) 无头浏览器无法截图——Cookie 注入添加截图功能

Q2：Cookie 存储的安全最佳实践中，为什么建议使用"专用的自动化账号"而非个人主账号？

• A) 自动化账号的 Cookie 过期更慢
• B) 隔离风险——如果自动化脚本出现 bug（如误操作删除了数据），影响的是自动化账号而非你的个人主账号（如误删了你的个人订单）
• C) 个人主账号的 Cookie 无法被提取
• D) 自动化账号可以绕过网站的反爬虫检测

Q3：setup-browser-cookies 的完整工作流程包含"打开真实浏览器 → 手动登录 → 提取 Cookie → 保存 → 后续自动注入"。请问：为什么必须"手动登录一次"——为什么不能通过脚本自动输入密码？这与"不要保存支付/银行类网站的 Cookie"这条最佳实践有什么关联？

Q4：Cookie 存储安全策略中提到"不在 CI 中使用"、"定期轮换"、"加密存储（可选，通过系统 keychain）"。请设计一个完整的 Cookie 生命周期管理方案：从 Cookie 的创建（首次登录）、使用（$B 自动注入）、轮换（Cookie 过期后重新配置）、到销毁（项目不再需要该网站访问权限）。在每个阶段，安全风险是什么？如何缓解？

Q5：电商后台场景中，setup-browser-cookies 配置了 admin.mega-shop.com 的登录 Cookie。这个 Cookie 让 $B 命令可以自动化访问后台的订单管理、退款审批、库存管理。请问：这个"便利"的对应风险是什么？如果攻击者获取了这个 Cookie 文件（~/.gstack/cookies/admin.mega-shop.com.json），他们能做什么？如何在不牺牲便利性的前提下降低风险？

Q6：Cookie 有过期时间（expiry）。当保存的 Cookie 过期后，$B goto 会静默失败（看起来页面加载了但实际上是登录页面而非目标页面）。setup-browser-cookies 应该如何设计"Cookie 过期检测"——是在每次 $B goto 时检查，还是在定期维护任务中检查？如果检测到过期，应该如何通知用户（静默失败 vs 主动告警）？你的方案如何避免"用户以为自动化在工作，实际上因为 Cookie 过期已经失败了一周"这种静默故障？

---

§6 答案

点击查看答案

Q1：B —— 无头浏览器的认证困境：每次都是全新 Chromium session，没有登录状态（没有 Cookie、没有 localStorage、没有保存的密码），无法访问任何需要认证的页面。

Q2：B —— 使用专用自动化账号的核心价值是隔离风险。

Q3：手动登录的必要性：如果脚本可以自动输入密码，密码必须以某种形式存储（明文在配置文件中 / base64 编码在环境变量中 / 硬编码在脚本中）。任何一种存储方式都意味着"获取了脚本访问权 = 获取了密码"——密码泄露的风险远大于 Cookie 泄露（密码可以用于任何设备登录、可以修改密码/邮箱等账号设置；Cookie 仅限当前 session、有过期时间、通常不能修改账号设置）。不要保存支付/银行 Cookie 的关联：支付和银行网站的价值太高——即使只是 Cookie（非密码），获取 Cookie 的人也能在 Cookie 有效期内冒充你进行交易。而 Cookie 存储文件（~/.gstack/cookies/）虽然有 0600 权限保护，但如果设备被恶意软件入侵，文件可能被读取。

Q4：完整生命周期：①创建——用户手动登录后，Cookie 被提取并保存。风险：提取过程中 Cookie 在内存中短暂存在（可能被内存 dump 工具捕获）。缓解：加密存储，提取后立即从内存中清除明文。②使用——$B goto 时自动注入 Cookie 到无头浏览器。风险：注入过程中的 Cookie 在 Playwright context 中存在（如果 Playwright 进程被攻击者调试，Cookie 可被读取）。缓解：使用短暂的 Playwright session，操作完成后立即关闭 browser context。③轮换——Cookie 过期后提示用户重新登录。风险：Cookie 过期前的那段时间，攻击者如果获取了旧 Cookie 仍然有效。缓解：在 Cookie 到期前 7 天主动提醒用户重新配置（提前轮换减少攻击窗口）。④销毁——项目不再需要访问该网站时删除 Cookie 文件。风险：忘记删除 = 过期的 Cookie 文件残留在磁盘上（虽然 Cookie 已过期但结构信息（域名、路径）仍可被用于社会工程攻击）。缓解：/retro 定期扫描并报告"有哪些 Cookie 配置文件超过 N 天未使用"。

Q5：风险：如果攻击者获取了 admin.mega-shop.com 的 Cookie 文件 → 攻击者可以在自己的 Playwright 实例中注入这些 Cookie → 以管理员的身份访问电商后台 → 查看所有订单数据（用户隐私泄露）→ 修改库存/价格 → 通过退款审批 → 导出用户数据库。这取决于 Cookie 的权限范围——如果 Cookie 对应的是 full-admin 权限账号，攻击者获得了完全的后台控制权。降低风险的方案：①使用专用自动化账号而非 admin 主账号，自动化账号只授予"仅够完成任务"的权限（如只能查看订单但不能退款）；②定期自动轮换 Cookie（每 24 小时强制要求重新登录）；③在 $B 操作时添加"操作审计"——每一步 $B click 都截图留证，异常操作模式（如凌晨 3 点批量导出订单）触发告警。

Q6：Cookie 过期检测方案：在每次 $B goto 后检查页面内容——如果 URL 被重定向到登录页面（/login）或页面标题为"请登录"或页面中包含"Sign in"文本→ 判定 Cookie 已过期 → 立即报告而非静默失败。主动告警设计：$B goto 返回的响应中应该包含一个 auth_status 字段（AUTHENTICATED / EXPIRED / UNKNOWN）。如果为 EXPIRED → ①在终端输出中红色标记"⚠ Cookie 已过期，当前操作在未认证状态下执行"；②如果是在自动化流程中（如 canary 监控回路），发送告警而非继续运行（因为后续所有 $B 操作都不可靠）；③记录到审计日志中（"2026-05-03 canary 第 5 次检查：Cookie 过期，验证无效"）。防止静默故障的关键：不能让"操作似乎成功了"的假象持续——Cookie 过期后 $B goto 仍然返回 200 OK（登录页面也是 200），但后续的 $B text 会提取到"请输入用户名"而非"待处理退款：3 笔"。必须有一层"内容验证"（$B goto 后 assert 页面包含预期内容的关键词）——如果关键词不匹配 → 判定验证失败（可能是 Cookie 过期 / 网站改版 / 部署失败）。

（5/6 通过）

---

延伸阅读

• [[L6-38-AI浏览器控制台|上一课：AI浏览器控制台]]
• [[L6-40-设计深度审计|下一课：设计深度审计]]