Selenium Cookie复用跳过验证码的工程实践

张

张建站

2026/5/22 2:12:01

10分钟阅读

1. 这不是“绕过”而是“跳过”——先厘清一个关键认知误区很多人看到“Selenium通过cookie绕过验证码”这个标题第一反应是这算不算在钻系统空子会不会被风控拦截甚至担心是不是游走在合规边缘我做自动化测试七年带过二十多个中大型项目的UI自动化落地实话讲这不是绕过而是跳过不是对抗而是复用。核心在于——你登录成功的那一次服务端已经为你签发了合法、有效、带完整会话权限的cookie而验证码只在身份未确认阶段即登录页/注册页/敏感操作前置页强制校验。一旦用户完成人机验证并成功认证后续所有请求都依赖session或token维持状态验证码机制自然退出生命周期。所以“通过cookie跳过验证码”的本质是在自动化流程中复用已认证的会话凭证跳过前端交互层中重复、低效、且对机器不友好的人机挑战环节。它不破解验证码算法不模拟点击滑块轨迹不调用OCR识别接口更不尝试暴力穷举。它只是像真实用户那样在第一次手动登录后把浏览器里那个带着JSESSIONID、auth_token、user_session等字段的cookie字符串原样注入到Selenium驱动的新会话中让服务端“误以为”这是同一个已登录用户发起的后续操作。这个做法在内部测试环境、灰度发布验证、回归测试流水线中极为常见。比如我们团队维护的电商后台系统每天要跑300条订单管理、库存同步、促销配置类用例如果每条都从登录页开始走完整流程——输入账号密码、等待图形验证码加载、人工识别、点击提交、等待跳转……光是登录环节就吃掉40%以上的执行时间还极易因验证码识别失败导致整条链路中断。而采用cookie预置方案后单次用例平均执行耗时从82秒降至13秒失败率从17%压到0.3%以下。关键词“Selenium自动化测试”“cookie”“验证码”在此场景中各自承担明确角色“Selenium”是执行载体负责控制浏览器行为“cookie”是状态凭证承载服务端授予的会话合法性“验证码”则是被跳过的前置校验关卡仅在身份建立初期生效。三者关系不是对抗而是分层协作——就像你进公司大楼第一次需要刷工卡人脸识别验证码但进了门之后去茶水间倒水、去会议室开会保安不会拦你再刷一次脸。cookie就是那张已被系统认可的“电子工卡”。提示该方案仅适用于测试环境或允许会话复用的预发布环境。生产环境严禁硬编码或明文存储生产cookie也不应将人工登录凭证用于无人值守的自动化任务——这违反基本的安全审计原则。本文所有实践均默认部署在隔离的测试集群且cookie有效期严格控制在2小时以内由CI/CD流水线动态生成与销毁。2. 为什么不用自动识别——三种主流方案的成本-收益对比既然目标是“不输验证码”那为什么不直接上OCR识别、打码平台或深度学习模型这个问题我在三次技术评审会上都被问到。答案很实在不是不能而是不值。我们做过详细测算把“验证码处理”拆成三类典型路径从开发成本、维护成本、稳定性、合规性四个维度横向对比方案类型开发投入人日日常维护周均稳定性成功率合规与安全风险Cookie预置法0.5写入逻辑序列化基本为零仅需更新过期策略≥99.6%依赖服务端session有效性极低仅限测试环境无凭证外泄开源OCR识别如tesseract3~5图像预处理阈值调优容错逻辑2h/周应对字体/噪点/扭曲变化72%~89%简单数字型尚可中文/干扰线型骤降至41%中需本地部署图像处理库存在资源占用商用打码平台API如某验、极验1封装HTTP请求错误重试1h/周监控扣费、处理限流、更新密钥92%~96%依赖第三方SLA网络抖动即失败高引入外部依赖存在数据上传合规风险数据背后是血泪教训。去年Q3我们曾在一个金融客户项目中强行推进OCR方案前期花4天调通tesseract适配了他们自研的5种验证码变体数字字母混合、斜切、加干扰线、背景色块、动态GIF帧。结果上线两周后对方运维突然升级了验证码服务——新增了“鼠标移动轨迹校验”要求用户必须以非匀速方式拖动滑块否则即使OCR识别正确也拒绝提交。我们连夜补轨迹模拟又搭上3天刚测通对方又切到了“行为式验证”连滑块都没了变成“请在3秒内完成指定动作序列”。最后团队一致决定砍掉整个OCR模块改用cookie预置人工触发登录态刷新机制。这就是现实——验证码的本质是持续对抗而自动化测试的核心诉求是稳定交付。你永远追不上风控策略的迭代速度但你可以牢牢抓住“已认证状态”这个确定性锚点。Cookie预置法的优势正在于此它不跟验证码斗智斗勇而是直接站在验证完成后的终点线上出发。只要服务端session机制没重构比如从cookie切到JWT无状态token且校验IP绑定这套方案就能稳稳跑三年以上。注意若目标系统采用JWT且校验设备指纹或IP白名单cookie注入后仍可能被拒绝。此时需同步注入User-Agent、X-Forwarded-For等请求头并确保Selenium启动的浏览器User Agent与原始登录环境一致。这点常被忽略导致“明明cookie是对的却提示未登录”。3. 实操四步法从手动登录到自动化复用的完整链路真正落地时很多人卡在“怎么拿到cookie”“怎么塞进去”“为什么还是跳转登录页”这三个问题上。下面是我打磨出的四步标准流程已在8个不同技术栈项目Spring Boot、Django、Node.js、PHP Laravel中验证有效每一步都附带避坑要点。3.1 第一步人工登录并导出完整cookie集合别急着写代码先打开Chrome浏览器访问测试环境登录页如https://test-admin.example.com/login输入测试账号密码完成验证码验证成功进入首页。此时按F12打开开发者工具切换到Application → Cookies左侧选中当前域名右侧列表会显示所有已设置的cookie。重点不是只复制JSESSIONID很多同学只抓这个结果失败。你需要导出全部非HttpOnly标记的cookieHttpOnly字段无法被JS读取Selenium也无法注入但服务端仍会校验其存在性——所以必须保留原始会话中的HttpOnly cookie靠Selenium启动时自动携带。实际操作中我推荐用Chrome插件“EditThisCookie”一键导出JSON格式安装插件后点击图标 → “Export” → 选择“JSON”格式保存为login_cookies.json内容类似[ { domain: .test-admin.example.com, expirationDate: 1735689200, hostOnly: false, httpOnly: true, name: JSESSIONID, path: /, sameSite: Lax, secure: true, session: false, storeId: 0, value: ABCD1234-EFGH5678-IJKL9012-MNOP3456, id: 1 }, { domain: .test-admin.example.com, expirationDate: 1735689200, hostOnly: false, httpOnly: false, name: auth_token, path: /, sameSite: Lax, secure: true, session: false, storeId: 0, value: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..., id: 2 } ]关键细节务必检查domain字段是否带前导点号如.test-admin.example.com这是跨子域共享cookie的关键。若导出的是test-admin.example.com无点号需手动补上否则注入后子域页面无法读取。3.2 第二步编写Selenium初始化脚本注入cookie并验证状态核心逻辑是启动浏览器 → 访问任意页面建议用about:blank避免触发重定向→ 调用add_cookie()逐条注入 → 刷新页面 → 检查是否跳转登录页。Python Selenium 4.x代码示例如下from selenium import webdriver from selenium.webdriver.chrome.options import Options from selenium.webdriver.common.by import By import json import time def init_driver_with_cookies(cookie_file_path: str, target_url: str https://test-admin.example.com/dashboard): # 1. 启动无GUI Chrome测试环境推荐 chrome_options Options() chrome_options.add_argument(--headless) chrome_options.add_argument(--no-sandbox) chrome_options.add_argument(--disable-dev-shm-usage) chrome_options.add_argument(--disable-gpu) # 2. 必须先访问目标域名根路径否则add_cookie会报错 driver webdriver.Chrome(optionschrome_options) driver.get(https://test-admin.example.com) # 先访问同域任意页 # 3. 读取并注入cookie with open(cookie_file_path, r, encodingutf-8) as f: cookies json.load(f) for cookie in cookies: # 过滤掉HttpOnly字段Selenium无法设置但服务端需要所以跳过 if cookie.get(httpOnly, False): continue # 构造符合Selenium要求的cookie字典 selenium_cookie { name: cookie[name], value: cookie[value], domain: cookie[domain], path: cookie.get(path, /), secure: cookie.get(secure, False), httpOnly: cookie.get(httpOnly, False), } # Selenium 4要求显式设置expiry单位秒非毫秒 if expirationDate in cookie and cookie[expirationDate]: selenium_cookie[expiry] int(cookie[expirationDate]) try: driver.add_cookie(selenium_cookie) except Exception as e: print(fFailed to add cookie {cookie[name]}: {e}) continue # 4. 注入完成后访问目标页面并验证登录态 driver.get(target_url) time.sleep(2) # 等待页面加载 # 检查是否仍在登录页根据实际DOM判断 try: login_form driver.find_element(By.ID, login-form) if login_form.is_displayed(): raise RuntimeError(Cookie injection failed: still on login page) except: pass # 找不到登录表单说明已进入目标页 return driver # 使用示例 if __name__ __main__: driver init_driver_with_cookies(login_cookies.json) print(Login state verified. Ready for test steps.) # 后续执行你的业务操作...实操心得driver.get(https://test-admin.example.com)这行绝不能省Selenium要求必须先访问同域页面才能注入cookie否则抛Unable to set Cookie异常。很多新手直接get(about:blank)然后注入必败。3.3 第三步处理HttpOnly cookie的“隐形依赖”前面提到HttpOnly cookie无法被JS读取Selenium也无法主动设置。但服务端校验时它往往和JSESSIONID强绑定——比如Spring Session默认会生成SESSIONHttpOnly和_csrf非HttpOnly两个cookie缺一不可。如果你只注入了_csrf服务端收到请求时发现SESSION缺失或无效依然会302跳回登录页。解决方案有两个且必须二选一方案A推荐用同一浏览器实例复用HttpOnly cookie不关闭浏览器保持会话活跃。在人工登录后不要关掉这个Chrome窗口而是用Selenium的remote模式连接到它from selenium import webdriver from selenium.webdriver.remote.webdriver import WebDriver # 启动Chrome时加上 --remote-debugging-port9222 # 手动登录完成后用以下代码接管 options webdriver.ChromeOptions() options.add_experimental_option(debuggerAddress, 127.0.0.1:9222) driver webdriver.Chrome(optionsoptions) # 此时driver直接继承了人工登录的所有cookie含HttpOnly优点100%保真无需任何转换。缺点需人工介入启动不适合全无人值守CI。方案B服务端配合临时关闭HttpOnly校验仅限测试环境联系后端同事在测试环境配置中将server.servlet.session.cookie.http-onlyfalseSpring Boot或对应框架开关让所有session cookie变为可读写。这样你导出的JSON就包含全部字段注入后完全等效。踩坑记录某次我们用方案A但忘记在Chrome启动参数中加--user-data-dir/tmp/chrome-test导致每次接管都加载默认用户配置HttpOnly cookie丢失。后来固定使用独立用户目录问题解决。3.4 第四步构建可持续的cookie刷新机制cookie会过期这是最大痛点。我们设计了一个轻量级刷新服务每天凌晨2点用Jenkins调度一个“保活任务”启动一个带GUI的Chrome测试机需配置Xvfb虚拟桌面自动执行登录流程重新导出最新cookie并覆盖login_cookies.json。关键代码片段# Jenkins执行的shell脚本 export DISPLAY:99 Xvfb :99 -screen 0 1024x768x24 sleep 2 python3 refresh_login.py # 该脚本含完整登录验证码识别仅此处用OCR因频次极低 killall Xvfbrefresh_login.py里用tesseract识别验证码虽有失败可能但因每天只跑1次失败后邮件告警人工介入即可不影响日常测试。相比每条用例都OCR成本降低99%。4. 十二个高频故障排查清单从“页面闪退”到“403 Forbidden”的归因树即便流程写得再完美实际运行中仍会遇到各种诡异问题。我把过去两年收集的117个报错案例浓缩成12个最高频故障点按“现象→根因→验证方法→修复动作”结构整理方便你快速定位4.1 现象页面加载后立即跳转到登录页Network面板显示302重定向根因注入的cookie域名不匹配如导出时domain是.example.com但目标URL是admin.example.com而Selenium注入时未正确解析子域验证在注入cookie后、get(target_url)前执行print(driver.get_cookies())检查输出中是否有你注入的cookie名称修复确保cookie JSON中domain字段为.example.com带前导点且target_url的域名属于该域的子域4.2 现象控制台报错WebDriverException: Message: invalid argument: cookie must be an object with a name property根因cookie字典缺少必要字段或字段类型错误如expiry传了字符串而非整数验证打印len(cookies)和cookies[0].keys()确认字段完整性修复严格按Selenium文档要求构造cookie字典expiry必须为int(time.time()) 72004.3 现象页面显示“登录态异常请重新登录”但Network请求返回200根因服务端校验了User-Agent或Referer而Selenium默认UA与人工登录时不同验证人工登录时抓包看请求头对比Selenium请求头用driver.execute_script(return navigator.userAgent)获取修复启动Chrome时添加--user-agentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36...UA值从人工登录抓包中复制4.4 现象注入后能进首页但点击菜单报403 Forbidden根因后端RBAC权限校验依赖cookie外的其他凭证如localStorage中的permissions数组或请求头中的X-Auth-Token验证人工登录后执行localStorage.getItem(permissions)再在Selenium中执行相同命令修复在注入cookie后用driver.execute_script(localStorage.setItem(permissions, arguments[0]), json.dumps(perm_list))同步写入4.5 现象Chrome启动后空白页进程卡死根因--headless模式下某些验证码JS检测到无GUI环境主动阻断流程验证去掉--headless参数观察是否正常修复改用--headlessnewChrome 109或添加--disable-blink-featuresAutomationControlled4.6 现象cookie注入成功但后续AJAX请求仍401根因前端框架如Vue Router在路由守卫中调用axios.defaults.headers.common[Authorization]而该header未随cookie自动携带验证Network面板查看失败请求的Headers确认Authorization字段是否存在修复注入cookie后执行driver.execute_script(window.axios.defaults.headers.common[Authorization] Bearer arguments[0], auth_token_value)4.7 现象多线程运行时部分线程报“Session not found”根因多个Selenium实例共用同一cookie文件而服务端session被其中一个实例登出如调用了/logout接口验证检查测试脚本中是否有全局logout操作或CI并发数超过服务端session上限修复为每个线程生成独立cookie副本或限制CI并发为14.8 现象Mac系统下注入cookie后页面白屏根因Safari/Chrome在macOS对SameSiteNonecookie的处理更严格要求同时设置Securetrue验证检查cookie JSON中secure字段是否为true且目标URL是否为HTTPS修复确保测试环境启用HTTPS或在cookie中显式设置secure: true4.9 现象Docker容器中运行失败报错“cannot connect to X server”根因容器内无X11环境而脚本尝试启动GUI浏览器验证检查是否误用了--headlessfalse修复Dockerfile中安装xvfb启动命令改为xvfb-run -a python3 test.py4.10 现象登录后能操作但10分钟后自动登出根因服务端session超时时间如Tomcat的maxInactiveInterval短于cookie有效期验证人工登录后等待10分钟再操作确认是否登出修复调整服务端session timeout至≥2小时或增加定时刷新请求如每5分钟GET/api/keepalive4.11 现象Firefox下cookie注入后无效Chrome正常根因Firefox对SameSite属性解析更严格要求Lax或Strict而导出cookie为None验证检查cookie JSON中sameSite字段值修复将sameSite: None改为sameSite: Lax或启动Firefox时添加--samesite-default-cookiesLax4.12 现象一切正常但截图显示页面顶部有黄色“Chrome正受到自动测试软件控制”横幅根因Chrome检测到自动化标志部分前端JS据此禁用功能验证手动关闭该横幅看功能是否恢复修复启动参数添加--disable-infobars --disable-extensions --disable-dev-shm-usage --no-sandbox --disable-gpu --disable-featuresEnableEphemeralStorage最后分享一个技巧在CI流水线中我习惯在cookie注入后加一段“黄金验证”——不是检查某个元素是否存在而是直接调用driver.execute_script(return window.location.href)确认返回值是目标URL而非登录页URL。这个动作耗时不到100ms却比任何DOM检查都可靠因为它是服务端302重定向的真实反映。5. 超越登录把cookie思维扩展到整个测试生命周期做到“跳过验证码登录”只是起点。真正让这套方案产生复利的是把它作为测试状态管理的基础设施来设计。我在三个项目中实践了这种升维用法效果远超预期。5.1 场景一跨用例状态传递消灭重复登录开销传统UI自动化中每个测试用例都是独立的setUp()→test()→tearDown()闭环意味着100个用例就要登录100次。我们改造了pytest的fixture机制创建一个shared_sessionfixtureimport pytest from selenium import webdriver pytest.fixture(scopesession) def shared_driver(): # 1. 从缓存读取有效cookie带时间戳校验 cookies load_fresh_cookies() # 2. 启动driver并注入 driver init_driver_with_cookies(cookies) yield driver # 3. 用例全部跑完后再退出 driver.quit() # 所有用例直接使用 def test_order_creation(shared_driver): shared_driver.get(https://test-admin.example.com/orders/new) # ... 业务操作 def test_inventory_check(shared_driver): shared_driver.get(https://test-admin.example.com/inventory) # ... 业务操作结果100个用例总执行时间从3小时12分压缩到28分钟且因避免了频繁登录导致的session冲突稳定性提升至99.92%。5.2 场景二模拟多角色协同复用不同权限cookie电商后台需验证“运营配置促销”→“客服查询订单”→“财务审核结算”的全链路。我们为每个角色准备独立cookie文件operator_cookies.json、cs_cookies.json、finance_cookies.json并在用例中动态切换def test_cross_role_workflow(): # 1. 运营配置 op_driver init_driver_with_cookies(operator_cookies.json) op_driver.get(/promotions/create) # ... 创建促销 # 2. 切换客服视角不退出driver直接注入新cookie cs_driver op_driver # 复用同一实例 clear_all_cookies(cs_driver) inject_cookies(cs_driver, cs_cookies.json) cs_driver.get(/orders?statuspaid) # ... 查询订单 # 3. 切换财务视角 fin_driver cs_driver clear_all_cookies(fin_driver) inject_cookies(fin_driver, finance_cookies.json) fin_driver.get(/settlements/verify) # ... 审核结算关键在clear_all_cookies()函数——它遍历所有domain下的cookie并逐个删除比直接driver.delete_all_cookies()更彻底避免残留旧session。5.3 场景三与API测试打通构建全栈状态一致性UI测试和API测试常出现“UI能操作API却报错”的割裂。根源是两者使用不同会话。我们让API测试也复用同一套cookieimport requests def api_request_with_ui_session(endpoint: str, cookies_json: str): # 1. 解析cookie JSON构造requests可用的cookie jar jar requests.cookies.RequestsCookieJar() with open(cookies_json) as f: for c in json.load(f): if not c.get(httpOnly, False): # 只取非HttpOnly的 jar.set(c[name], c[value], domainc[domain], pathc[path]) # 2. 发起请求自动携带cookie response requests.get(fhttps://test-api.example.com{endpoint}, cookiesjar) return response # UI测试中获取当前有效cookie def get_current_cookies(driver): # 用execute_script读取document.cookie仅非HttpOnly部分 raw_cookie driver.execute_script(return document.cookie) # 解析为字典... return parsed_dict这样当UI测试中创建了一个订单API测试能立刻用同一session查询该订单详情真正实现“所见即所得”的全栈验证。我在最近一个政务系统项目中把这套cookie状态管理封装成独立PyPI包test-session-manager内部已沉淀17个开箱即用的工具函数从“自动续期cookie”到“跨浏览器同步状态”团队新人两天就能上手。真正的自动化不是让机器多干活而是让人少操心。当你把登录这个最琐碎的环节彻底抽象掉才能把精力聚焦在真正有价值的业务逻辑验证上。