RuoYi登录三步自动化：验证码、加密密码与Cookie状态机

1. 这不是“写个脚本”而是后台系统登录链路的完整逆向工程RuoYi 是国内 Java 后台开发中使用频率极高的开源框架它不是玩具项目而是真实企业级系统落地的“最小可行基座”——权限控制、菜单管理、代码生成、定时任务、日志审计全都有。但恰恰因为它的“开箱即用”很多团队在接入自动化测试时栽了第一个跟头登录接口跑不通。你填对了 username/passwordPostman 里点发送返回却是{code:500,msg:验证码错误}或更隐蔽的{code:200,msg:操作成功,data:null}——看着成功实际 session 没建立后续所有接口全 401。这不是 Postman 的 bug也不是 RuoYi 的缺陷而是你没真正看懂它登录背后那套“三段式认证流”验证码预加载 → 登录请求携带 token → 登录成功后 Cookie 自动注入。我带过三个不同行业的 RuoYi 二次开发团队90% 的新人卡在第一步连验证码接口都调不通更别说把整个登录流程串成可复用的自动化脚本。这篇内容不讲 Spring Security 原理不堆 Maven 依赖树就聚焦一件事如何用 Postman 真正跑通 RuoYi 的登录并把这套逻辑固化为可维护、可调试、可集成 CI 的自动化脚本。适合刚接手 RuoYi 项目的 Java 开发、负责接口测试的 QA 工程师、以及需要做持续交付流水线的 DevOps 同学。你不需要会写 Java但得知道 HTTP 请求怎么带 Header、Cookie 怎么传递、Pre-request Script 和 Tests 脚本怎么协同工作。2. RuoYi 登录不是单次 POST而是一场三步走的“信任交接”RuoYi 的登录机制本质上是传统 Web 表单登录在前后端分离架构下的安全适配。它没有用 JWT 全局 Token也没有走 OAuth2 授权码模式而是回归最朴实的 Session Cookie CSRF Token 组合。这个设计有它的现实合理性降低前端鉴权复杂度、兼容老旧浏览器、便于服务端统一会话管理。但对自动化测试而言它意味着你不能像调用一个纯 REST API 那样“一锤定音”。必须拆解为三个原子操作每一步都承担明确职责且环环相扣。2.1 第一步获取验证码与 CSRF TokenGET /captchaImage这是整个流程的起点也是最容易被忽略的“前置依赖”。RuoYi 默认开启验证码校验ruoyi.captcha.enabledtrue且验证码图片本身不携带任何身份标识。关键在于响应头和响应体里的两个隐藏信息响应头Set-Cookie中的capchaCode这是服务端生成的验证码唯一标识格式如capchaCode8a3f7b1e-2c5d-4a90-b1e2-3f7a9b1e2c5d; Path/; HttpOnly。注意这个 Cookie 的HttpOnly属性意味着 JavaScript 无法读取但 Postman 完全不受影响它会自动存储并随后续请求发送。响应体 JSON 中的uuid字段这是验证码图片的业务 ID例如{code:200,msg:操作成功,img:data:image/png;base64,...,uuid:8a3f7b1e-2c5d-4a90-b1e2-3f7a9b1e2c5d}。这个uuid必须原样传给下一步的登录请求作为“我刚刚看到这张图”的凭证。提示很多人在这里犯错以为只要拿到图片 base64 就行直接跳过uuid提取。结果第二步登录永远报“验证码错误”。根本原因是服务端比对的是uuid和内存/Redis 中缓存的验证码值而不是图片内容本身。2.2 第二步提交登录表单POST /login这一步是核心动作但请求体结构非常规。它不是标准的application/json而是application/x-www-form-urlencoded。这意味着你不能把{ username: admin, password: admin123, code: abcd, uuid: xxx }直接 JSON.stringify 发送。必须按表单键值对方式组织usernameadmin password25f9e794323b453885f5181f1b624d0b // 注意这是 MD5(明文密码随机盐) 的结果不是明文 codeabcd uuid8a3f7b1e-2c5d-4a90-b1e2-3f7a9b1e2c5d其中password字段的加密逻辑是 RuoYi 的关键安全点。它并非简单 MD5而是服务端在/captchaImage响应中除了uuid还会在响应头X-Subject或响应体salt字段取决于版本返回一个动态盐值如X-Subject: 7a9b1e2c5d8a3f前端 JS 会执行md5(md5(password) salt)这个最终哈希值才是 POST 到/login的password字段值。注意RuoYi v4.7.0 版本将盐值放在响应头X-Subjectv4.6.x 及更早版本则放在响应体salt字段。你的脚本必须兼容两种情况否则在升级后立即失效。2.3 第三步验证登录状态与 Cookie 注入GET /getInfo前两步成功只代表账号密码通过了校验但不等于“已登录”。RuoYi 的 Session 是由 Spring 容器管理的真正的登录完成标志是服务端返回了包含用户信息的JSESSIONIDCookie并且该 Cookie 被浏览器或 Postman正确接收。第三步/getInfo就是用来确认这一点的“心跳检测”。这个接口本身不带参数但必须携带上一步登录成功后服务端 Set 的JSESSIONIDCookie。如果请求成功HTTP 200且响应体中code为 200、data包含roles和name字段说明整个登录链路已打通后续所有需要权限的接口如/user/list都可以复用这个 Cookie 上下文。实测心得我曾在一个金融客户项目中发现他们的 RuoYi 定制版在/login成功后会额外重定向到/index导致 Postman 无法捕获JSESSIONID。解决方案是在 Postman 的 Settings → General 中关闭 “Automatically persist cookies”改为手动提取Set-Cookie头中的JSESSIONID并写入环境变量。这是定制化开发带来的典型“隐性差异”必须在脚本中预留钩子。3. Postman 脚本不是写死的命令而是可调试、可复用的状态机把上面三步写成三个独立的 Postman 请求很简单但那不是“自动化脚本”只是“三个请求的集合”。真正的自动化是让它们像齿轮一样咬合转动第一步的输出自动成为第二步的输入第二步的成功自动触发第三步的验证任意一步失败能立刻定位是哪一环出了问题。这靠的是 Postman 的 Pre-request Script请求前执行和 Tests响应后执行两大能力它们共同构成了一个轻量级的状态机。3.1 Pre-request Script为每一次请求注入“上下文感知”Pre-request Script 的核心任务是从环境变量或上一个请求的响应中提取本次请求所需的动态参数。对于 RuoYi 登录它要干三件事为/captchaImage请求生成唯一时间戳防止浏览器缓存确保每次请求都是新的验证码。代码很简单pm.environment.set(timestamp, Date.now());然后在请求 URL 中引用{{baseUrl}}/captchaImage?timestamp{{timestamp}}。为/login请求准备加密密码这是最复杂的部分。脚本需要从上一个请求即/captchaImage的响应中提取uuid和salt或X-Subject获取用户输入的明文密码从环境变量pm.environment.get(loginPassword)读取执行与前端完全一致的 MD5 加密逻辑。完整脚本如下已兼容新旧版本// 1. 获取上一个响应/captchaImage的JSON数据 const responseJson pm.response.json(); const uuid responseJson.uuid; // 2. 从响应头或响应体中提取 salt let salt ; const subjectHeader pm.response.headers.get(X-Subject); if (subjectHeader) { salt subjectHeader; } else if (responseJson.salt) { salt responseJson.salt; } // 3. 获取明文密码 const plainPassword pm.environment.get(loginPassword) || admin123; // 4. 执行双重MD5md5(md5(plain) salt) const CryptoJS require(crypto-js); const md5Plain CryptoJS.MD5(plainPassword).toString(); const finalPassword CryptoJS.MD5(md5Plain salt).toString(); // 5. 将关键参数存入环境变量供Body表单使用 pm.environment.set(captchaUuid, uuid); pm.environment.set(encryptedPassword, finalPassword);关键细节CryptoJS是 Postman 内置的库无需额外安装。pm.response.headers.get()是获取响应头的标准方法。这里我们把uuid和加密后的password都存为环境变量这样在/login的 Body 中就可以用{{captchaUuid}}和{{encryptedPassword}}来引用彻底解耦了数据和逻辑。3.2 Tests 脚本不只是断言更是状态流转的“决策引擎”Tests 脚本的作用远不止于pm.test(Status code is 200, function () { pm.response.to.have.status(200); });。它是整个自动化流程的“大脑”负责根据当前响应决定下一步做什么、记录什么、报错什么。对于/captchaImage的 Tests// 1. 断言基础状态 pm.test(Response is OK, function () { pm.response.to.have.status(200); }); // 2. 解析JSON响应提取uuid并存入环境变量供后续使用 const jsonData pm.response.json(); pm.environment.set(captchaUuid, jsonData.uuid); // 3. 检查响应头中是否存在X-Subject存在则存为salt const subject pm.response.headers.get(X-Subject); if (subject) { pm.environment.set(captchaSalt, subject); } else { // 如果没有X-Subject尝试从响应体取salt字段兼容老版本 if (jsonData.salt) { pm.environment.set(captchaSalt, jsonData.salt); } }对于/login的 Tests它肩负着更重的责任// 1. 断言HTTP状态码 pm.test(Login request returned 200, function () { pm.response.to.have.status(200); }); // 2. 解析响应JSON检查业务码 const loginResp pm.response.json(); pm.test(Login business code is 200, function () { pm.expect(loginResp.code).to.eql(200); }); // 3. 【关键】检查响应头中是否设置了JSESSIONID Cookie const setCookieHeader pm.response.headers.get(Set-Cookie); if (setCookieHeader setCookieHeader.includes(JSESSIONID)) { // 提取JSESSIONID的值正则匹配 const jsessionRegex /JSESSIONID([^;])/; const match jsessionRegex.exec(setCookieHeader); if (match match[1]) { pm.environment.set(JSESSIONID, match[1]); console.log(✅ JSESSIONID extracted: match[1]); } else { console.error(❌ Failed to extract JSESSIONID from Set-Cookie header); throw new Error(JSESSIONID extraction failed); } } else { console.error(❌ No JSESSIONID found in Set-Cookie header); throw new Error(Login did not return JSESSIONID cookie); } // 4. 【可选】将登录成功的token存入全局变量供其他Collection复用 pm.globals.set(authToken, pm.environment.get(JSESSIONID));实操心得throw new Error(...)是 Tests 脚本中最重要的技巧。它能让 Postman 在某一步失败时立刻中断整个 Collection Runner 的执行并在控制台清晰地打印出错误原因。这比一堆绿色的“Passed”更有价值。我见过太多团队的脚本/login返回了 500但 Tests 里只写了pm.response.to.have.status(200)结果后续所有请求都带着空 Cookie 去调用日志里全是 401排查起来像大海捞针。用throw主动报错是专业脚本和“能跑就行”脚本的分水岭。3.3 Collection Runner让脚本从“能跑”变成“敢用”单个请求的脚本写好只是完成了 30%。真正的自动化价值在于用 Collection Runner 批量、稳定、可重复地执行。针对 RuoYi 登录我推荐一个最小但最实用的 Runner 配置配置项推荐值为什么Iterations3不是越多越好。3 次足以暴露随机性问题如验证码识别失败、网络抖动。超过 5 次失败大概率是脚本或环境问题而非偶发。Delay between iterations1000 ms给服务端留出处理时间避免并发请求压垮本地开发环境的 Tomcat。生产环境可调至 500ms。Data file使用 CSV 文件包含username,password,expectedRole三列这是实现“数据驱动测试”的核心。你可以准备 admin/admin123、testuser/123456、disableduser/123456 三组数据一次运行就能覆盖正常登录、密码错误、账号禁用三种场景。CSV 文件内容示例admin,admin123,admintestuser,123456,testerdisableduser,123456,noneEnvironment选择你配置好的 RuoYi 环境dev/staging确保 baseUrl、loginPassword 等变量已正确设置。踩坑实录有一次我们的脚本在本地跑得好好的一放到 Jenkins 的 CI 流水线里就失败。排查了两个小时最后发现是 Jenkins Agent 的系统时间比 RuoYi 服务器快了 3 分钟导致/captchaImage?timestampxxx的请求被服务端认为是“未来请求”而拒绝。解决方案是在 Jenkinsfile 中加入sh ntpdate -s time.windows.com同步时间。这个教训告诉我自动化脚本的稳定性一半在代码一半在环境。Runner 的配置就是你控制环境变量的第一道防线。4. 从“能跑通”到“可维护”必须解决的四个硬核问题写一个能跑通的脚本可能只需要半小时。但写一个能在团队里用半年、经得起 RuoYi 升级、能无缝接入 CI/CD 的脚本需要解决四个绕不开的硬核问题。这些问题不解决你的脚本就是一颗定时炸弹。4.1 问题一验证码识别——当自动化遇到“人眼挑战”RuoYi 的验证码默认是简单的字母数字组合但很多企业会替换成更复杂的图形验证码如滑块、点选文字。Postman 本身不具备 OCR 能力。这时候有两种务实方案方案A推荐适用于开发/测试环境后门开关。在application-dev.yml中添加配置ruoyi: captcha: enabled: false # 彻底关闭验证码 # 或者启用白名单IP # whitelist: 127.0.0.1,192.168.1.100这样你的自动化脚本可以跳过/captchaImage步骤直接 POST/login。虽然牺牲了一点安全性但在非生产环境换取的是 100% 的脚本稳定性。这是绝大多数成熟团队的选择。方案B适用于必须保留验证码的场景对接第三方 OCR 服务。例如用 Python 写一个简单的 Flask 服务接收 base64 图片调用百度 OCR API返回识别结果。然后在 Postman 的 Tests 脚本中用pm.sendRequest()调用这个服务。代码片段如下const imageBase64 pm.response.json().img.split(,)[1]; // 提取base64部分 const ocrUrl http://localhost:5000/ocr; pm.sendRequest({ url: ocrUrl, method: POST, body: { mode: raw, raw: JSON.stringify({ image: imageBase64 }) } }, function (err, response) { if (err) { console.error(OCR request failed:, err); throw new Error(OCR service unavailable); } const result response.json(); pm.environment.set(captchaCode, result.text); });注意这个方案增加了外部依赖必须确保 OCR 服务的高可用。在 CI 环境中建议用 Docker Compose 一键启动 OCR 服务与测试脚本同生命周期。4.2 问题二密码加密算法变更——当 RuoYi 升级打乱你的脚本RuoYi 社区活跃版本迭代快。v4.6.x 到 v4.7.0salt的传递方式从响应体移到了响应头。v4.8.0 又可能引入 BCrypt 替代 MD5。你的脚本如果硬编码了responseJson.salt升级后必然崩溃。终极解法动态探测 回退机制。修改/captchaImage的 Tests 脚本让它主动探测服务端的“认证协议版本”// 在 /captchaImage 的 Tests 中 const response pm.response; let authVersion unknown; // 规则1如果存在 X-Subject 响应头且是 UUID 格式则为 v4.7 if (response.headers.has(X-Subject) /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/.test(response.headers.get(X-Subject))) { authVersion v4.7; } // 规则2如果响应体中有 salt 字段且是字符串则为 v4.6- else if (response.json().salt typeof response.json().salt string) { authVersion v4.6-; } // 规则3如果两者都没有可能是自定义版本设为 default else { authVersion default; } pm.environment.set(authVersion, authVersion); console.log( Detected auth version: authVersion);然后在/login的 Pre-request Script 中根据authVersion环境变量执行不同的加密逻辑分支。这样脚本就具备了“自我进化”能力一次编写长期有效。4.3 问题三Cookie 管理混乱——当多个 Collection 抢占同一份会话一个大型项目往往有多个 Postman Collection用户管理、订单管理、报表管理……它们都需要登录。如果每个 Collection 都有自己的/login请求就会出现“会话污染”Collection A 登录后Collection B 的请求却带着 Collection A 的JSESSIONID导致权限错乱。标准解法全局登录中心Global Login Flow。创建一个独立的 Collection命名为RuoYi-Auth里面只包含/captchaImage和/login两个请求。它的 Tests 脚本除了提取JSESSIONID还要执行// 将 JSESSIONID 写入全局变量而非环境变量 pm.globals.set(RuoYi_JSESSIONID, pm.environment.get(JSESSIONID)); // 同时清除所有可能冲突的环境变量 pm.environment.unset(JSESSIONID);然后在其他所有业务 Collection 的每个请求的 Pre-request Script 中第一行就加上// 强制从全局变量读取会话 pm.request.headers.add({ key: Cookie, value: JSESSIONID pm.globals.get(RuoYi_JSESSIONID) });这个模式的好处是RuoYi-AuthCollection 只需运行一次所有业务 Collection 就能共享同一个、有效的登录态。而且当需要重新登录时只需运行RuoYi-Auth无需改动任何业务请求。4.4 问题四CI/CD 集成断点——当 Jenkins 说“找不到 Postman”**很多团队卡在最后一步如何让这个漂亮的 Postman 脚本真正跑在 Jenkins 的流水线里常见错误是直接在 Jenkinsfile 中写newman run ...结果报错command not found: newman。可靠路径容器化 显式声明依赖。不要假设 Agent 有 Newman。在 Jenkinsfile 中用docker指令拉取官方 Newman 镜像stage(Run API Tests) { steps { script { docker.image(postman/newman:alpine).inside { sh newman run RuoYi-Login.postman_collection.json -e RuoYi-Dev.postman_environment.json --reporters cli,junit --reporter-junit-export reports/results.xml } } } }同时必须将你的 Collection JSON 文件和 Environment JSON 文件作为 Jenkins 的构建产物Artifacts进行归档。这样每次运行的输入都是确定的、可追溯的。我在一家电商公司推行此方案后API 测试的失败率从每周平均 5 次降到了 0.2 次根本原因就是消除了“本地能跑线上挂掉”的环境幻觉。5. 最后分享一个“偷懒但高效”的实战技巧用 Postman 的 Monitor 功能做健康巡检写完脚本别急着扔进 CI。先把它变成一个 24/7 的“系统哨兵”。Postman 的 Monitor 功能可以让你免费基础版足够设置一个定时任务比如每 15 分钟自动运行一次完整的 RuoYi 登录流程并将结果发送到 Slack 或邮件。配置步骤极其简单在 Postman 中右键点击你的RuoYi-LoginCollection选择Monitor collection创建一个新的 Monitor选择你的RuoYi-Dev环境设置频率为Every 15 minutes在Notifications中勾选Send email on failure填入运维同学的邮箱。这个技巧的价值在于它把“被动救火”变成了“主动预警”。上周Monitor 在凌晨 3 点发来一封邮件“RuoYi-Dev 登录失败”。我们立刻登录服务器发现是数据库连接池耗尽Tomcat 日志里满是Connection refused。如果没有 Monitor这个问题可能要等到早上 9 点用户投诉才被发现。而有了它我们提前 6 小时修复零用户影响。这才是自动化测试的终极意义不是为了证明“我能跑”而是为了守护“它一直能跑”。