企业内网网站使用Session存储用户信息出现串号问题如何低代码解决

问题结论 #

该问题大概率是Session机制的错误实现/使用导致，并非Session本身的设计缺陷，常见错误场景和低改动解决方案如下：

快速根因排查步骤 #

你可以先通过2步快速定位具体原因：

• 打印用户A、B登录后服务端拿到的SessionID，确认二者是否相同
• 打印Session存储容器中对应SessionID的用户信息，确认是否出现后登录用户覆盖前者的情况

对应解决方案（代码改动量最小） #

场景1：SessionID相同（两个用户共用同一个Session） #

• 原因：自定义的SessionID生成逻辑有问题，相同内网IP的用户被分配了重复ID，或者SessionID没有和客户端做绑定
• 解决方案：直接改用服务端语言原生的Session实现，不要自研Session生成、存储逻辑。原生实现的SessionID碰撞概率几乎为0，且默认和客户端Cookie绑定，仅需要替换自定义Session的读写代码为原生语法即可，比如PHP直接用$_SESSION、Java用request.getSession()、Python Flask用session对象，业务逻辑完全不需要修改。

场景2：SessionID不同，但读取到的用户信息相同 #

• 原因：你们将用户Session信息存在了服务端全局静态变量中，所有请求共享同一个存储实例，后登录的用户B直接覆盖了全局变量里的用户信息，所有请求读取的都是最后写入的用户数据
• 解决方案：将全局存储的用户信息变量改为和当前请求绑定的上下文变量，比如Java用ThreadLocal存储、Python框架直接绑定到request对象属性，仅需要修改用户信息存、取两个工具方法的实现，上层业务调用不需要调整。

场景3：SessionID和存储内容都正常，但前端显示账号错误 #

• 原因：服务端的反向代理/CDN做了全局响应缓存，A的请求拿到了B登录后缓存的响应内容
• 解决方案：不需要修改任何业务代码，仅需要在服务端返回的响应头中增加Cache-Control: private，标识响应为用户私有内容，禁止代理层全局缓存即可。

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