中信国际inMotion项目Session id重复问题排查每日进展-20250228

SessionID重复 中信国际 AFA 赞同 java
1

中信国际inMotion项目Session id重复问题排查每日进展-20250228

进度

  1. 确认session​重复与UUID​无关，暂时不进行UUID测试
  2. 确认第二个用户登录时，获取到的是第一个用户的session​信息，此时用户请求报文并没有传递X-Session-ID​
  3. 确认第二个用户登录时，没有触发新建Session​的逻辑，即返回的是已存在的Session​对象
  4. 当前重点排查方向为：新登录请求返回已存在的Session​对象的原因

‍

分析

通过仔细分析日志，发现第一个用户登录和第二个用户登录输出的日志有一个明显的差异，第二个用户登录时日志中多了一个session=xxxxxxxx​的记录，而该记录对应的值就是第一个用户登录成功后的X-Session-ID​。

​image​

​image​

通过检查代码找到日志输出的位置：CommonsReqquestResponseLoggingFilter​

​image​

可以看到这里是获取了Session​并输出了id。而此时通过ELK检查日志，发现并没有触发Session​创建的逻辑，说明获取到的这个对象是已存在的。

同时通过日志也可以明确看到第二个登录的用户并没有传递X-Session-ID​，说明该对象的返回是不合理的，应该是

​CommonsReqquestResponseLoggingFilter​这个拦截器之前的某个代码返回的。

以Spring Session​的入口拦截器SessionRepositoryFilter​为分割点，将可能性分为两部分：

  1. 对象来自tomcat提供的Request​对象，由于Spring Session​将自己生成的Session​对象存放到Request​对象的attribute​中，如果Request​对象没有正确清理，那可能返回错误的session​
  2. 对象来自CommonsReqquestResponseLoggingFilter​和SessionRepositoryFilter​这两个拦截器中间的某个拦截器机制，由于拦截器允许通过包装的方式对request​对象进行多层包装，每一层包装都可能返回错误的session​

结合之前对tomcat机制的分析，以及日志中输出的其它请求信息都是正确的，基本上可以确认Request​对象是已经正确清理了的，所以先将1​的可能性调低，重点检查2​

通过debug以及代码检查，将两个过滤器中间的其它过滤器都列出来，其中后面标记1的过滤器是有包装request​对象的，需要深入分析其实现。

​d4df333096f18ee29166d2f304577e54​