使用JMeter测试/index.cfm/public:auth?fw1应用时遇403登录错误求助

1. 验证令牌提取的准确性 #

• 先确认正则表达式是否完整匹配所有令牌字段：你提到的xsrfTokenOrigin重复了，先核对前端实际返回的字段名，确保每个令牌（如xsrfTokenValue、正确的第二个令牌字段）都有对应的提取规则。
• 检查正则提取器的Template和Match No.设置，确保提取的变量值和浏览器DevTools中捕获的完全一致（包括大小写、特殊字符、引号等），可通过JMeter的View Results Tree查看变量实际取值。
• 确认doLogin请求中，令牌参数的字段名和前端提交的完全一致，避免拼写错误或参数名不匹配。

2. 简化Cookie处理逻辑 #

• 放弃BeanShell手动处理Cookie，改用JMeter内置的HTTP Cookie Manager：它会自动捕获并管理会话中的所有Cookie（AWSALB、AWSALBCORS、CFID、CFTOKEN、TA_SID），避免手动脚本的逻辑漏洞。
• 对比浏览器和JMeter的Cookie头：在View Results Tree中查看doLogin请求的Cookie信息，和浏览器DevToolsNetwork标签下的Cookie头逐一比对，确保无遗漏或值错误。
• 根据测试需求设置Clear cookies each iteration?选项：单会话测试不要勾选，多会话并发测试则勾选。

3. 核对请求的关键元数据 #

• 确认请求方法：doLogin是POST还是GET，必须和浏览器提交的方法完全一致。
• 检查请求头：
  • 必须包含正确的Content-Type（如application/x-www-form-urlencoded或application/json，以浏览器实际提交的为准）。
  • 补充Referer、Origin头等字段，部分应用会通过这些头验证请求合法性。
• 检查表单参数：除用户名、密码、令牌外，确认是否遗漏了fw1相关的隐藏参数，可通过浏览器DevTools的Form Data查看完整提交内容。

4. 验证JMeter配置修改的有效性 #

• 检查修改的配置项：
  • 确保cookie_manager.save.cookies=true已开启（默认开启，若手动修改过需确认）。
  • 设置httpclient4.retrycount=0，避免重试导致会话失效。
  • 暂时禁用HTTP Request中的Follow Redirects和Use KeepAlive，部分应用对重定向和长连接的处理会触发403。

5. 模拟完整会话流程 #

• 确保测试计划执行顺序正确：
  1. 先发送初始请求到/index.cfm/public:auth?fw1，获取初始Cookie和令牌。
  2. 提取所有必要的令牌和Cookie（使用Cookie Manager则无需手动提取Cookie）。
  3. 发送doLogin请求，携带所有参数、令牌和Cookie。
• 用Recording Controller录制浏览器的登录流程，对比录制脚本和手动编写的脚本，找出遗漏的头、参数或Cookie差异。

6. 定位403的具体原因 #

• 查看应用服务器日志：如果能获取服务器日志，直接查看403错误的触发原因（如令牌无效、Cookie过期、CSRF验证失败等），这是最直接的排查方式。
• 启用JMeter调试日志：修改log4j2.xml，将org.apache.jmeter.protocol.http的日志级别设为DEBUG，查看请求和响应的完整交互细节，对比和浏览器请求的差异。

内容的提问来源于stack exchange，提问作者HS Testing World