JMeter测试Temenos T24：Sv 06安全违规排查及JSESSIONID关联方案

一、Sv 06（Security Violation）错误排查与解决 #

常见成因 #

• T24安全校验机制触发，常见场景包括：
  • 请求缺失关键安全令牌（如CSRF token），录制时未捕获或后续请求未正确传递
  • 请求头参数不完整（比如User-Agent、Referer），与录制时的真实请求不一致
  • 会话上下文失效，比如JSESSIONID无效、未正确关联或已过期
  • 请求参数的顺序、格式不符合T24预期（部分T24接口对参数顺序敏感）
  • 测试场景的操作路径与录制时不一致，跳过了前置校验步骤

排查与解决步骤 #

1. 对比成功与失败请求的差异
   • 用JMeter的「查看结果树」工具，把失败请求和录制时的成功请求做逐字段对比：
     • 检查请求头：确保所有录制时存在的头信息（如X-Requested-With、Referer）都被完整保留，没有遗漏或修改
     • 核对请求参数：确认参数名称、值、顺序和成功请求完全一致，尤其是页面隐藏字段
     • 验证Cookie：检查JSESSIONID是否正确传递，是否存在过期或不匹配的情况
2. 检查并关联CSRF令牌
   • T24多数页面会生成CSRF令牌，通常藏在表单隐藏字段（如csrfToken、__RequestVerificationToken）或响应头中
   • 如果录制脚本时未自动捕获，给返回令牌的请求添加正则表达式提取器或CSS Selector提取器，提取令牌后在后续请求中作为参数传递
3. 优化Cookie管理器配置
   • 确保线程组下添加了「HTTP Cookie管理器」，多用户场景下勾选「Clear cookies each iteration?」，保证每个用户迭代时获取全新会话
   • 避免手动修改Cookie管理器中的内容，防止会话上下文冲突
4. 模拟真实用户请求行为
   • 添加「HTTP Header管理器」，设置和录制时一致的User-Agent、Accept、Accept-Language等头信息
   • 严格遵循真实用户的操作流程，比如先访问登录页再提交登录请求，不要直接跳过前置页面
5. 联系T24管理员排查系统配置
   • 若以上操作无效，可能是T24的安全策略限制（如IP白名单、会话超时过短），需要管理员检查SECURITY.CONTROL等相关安全配置文件

二、JSESSIONID关联与多用户登录会话管理 #

1. 从Cookie提取JSESSIONID为变量 #

JMeter的Cookie管理器会自动处理Cookie，但如果需要手动提取（比如跨域或特殊场景），可按以下步骤操作：

• 在返回JSESSIONID的请求（通常是第一个请求或登录请求）下添加正则表达式提取器：
  • 引用名称：JSESSIONID
  • 正则表达式：JSESSIONID=([^;]+)
  • 模板：$1$
  • 匹配数字：1
• 或者直接用Cookie管理器的变量导出功能：
  • 在「HTTP Cookie管理器」中勾选「Save cookies to variables?」，设置变量前缀（如COOKIE_），之后可通过${COOKIE_JSESSIONID}直接引用

2. 后续请求传递JSESSIONID实现多用户登录 #

推荐两种方式：

方式一：利用Cookie管理器自动管理（优先选择）

• JMeter默认每个线程拥有独立的Cookie上下文，只要勾选Cookie管理器的「Clear cookies each iteration?」，每个线程（用户）在迭代时会自动获取新的JSESSIONID，并在后续请求中自动传递，无需手动干预，完美适配多用户并发场景

方式二：手动在请求头中传递

• 如果需要手动控制，在后续请求的「HTTP Header管理器」中添加Cookie头：
  • 名称：Cookie
  • 值：JSESSIONID=${JSESSIONID}（${JSESSIONID}为之前提取的变量）
• 注意：手动传递时需禁用Cookie管理器的自动处理，避免Cookie冲突

内容的提问来源于stack exchange，提问作者Youssef hammad