1. 问题背景同一服务器多应用部署时的Cookie冲突上周在给客户部署一套微服务系统时遇到了一个典型的Cookie复用问题当两个Spring Boot应用部署在同一台服务器的不同端口时用户登录A系统后再访问B系统会自动带上A的会话信息导致权限混乱和异常跳转。这种问题在测试环境可能被忽视但上线后会造成严重的安全隐患。2. 核心原理Cookie的工作机制与域名绑定2.1 Cookie的默认作用域规则浏览器在处理Cookie时默认会根据以下三个要素判断是否发送域名匹配精确匹配或子域名Domain属性路径匹配Path属性协议一致Secure属性当这三个要素完全相同时即使服务端应用不同浏览器也会自动携带Cookie。在我们的案例中两个应用部署在应用Ahttp://server:8080/app1应用Bhttp://server:8081/app2由于未显式设置Domain和Path浏览器默认将Cookie绑定到server:8080和server:8081的根路径/导致跨应用传递。2.2 Spring Boot的默认Cookie配置通过调试发现Spring Session默认生成的Cookie具有以下特征JSESSIONIDxxxx; Path/; HttpOnly关键问题在于未设置Domain时浏览器自动绑定到当前访问的host:portPath/ 表示对所有子路径有效同名CookieJSESSIONID在多个应用间被覆盖3. 解决方案多维度隔离策略3.1 修改Cookie名称基础方案在application.properties中为每个应用设置唯一名称# 应用A配置 server.servlet.session.cookie.nameAPP1_SESSIONID # 应用B配置 server.servlet.session.cookie.nameAPP2_SESSIONID注意此方法仅解决Cookie覆盖问题未解决跨应用传递问题3.2 精确控制Cookie作用域推荐方案3.2.1 通过Nginx配置不同子域名upstream app1 { server localhost:8080; } upstream app2 { server localhost:8081; } server { listen 80; server_name app1.example.com; location / { proxy_pass http://app1; } } server { listen 80; server_name app2.example.com; location / { proxy_pass http://app2; } }3.2.2 应用层配置Configuration public class SessionConfig implements WebMvcConfigurer { Bean public CookieSerializer cookieSerializer() { DefaultCookieSerializer serializer new DefaultCookieSerializer(); serializer.setDomainName(example.com); serializer.setCookieName(APP_SPECIFIC_SESSION); serializer.setCookiePath(/); return serializer; } }3.3 高级防护SameSite属性配置在Spring Security配置中添加http.sessionManagement() .sessionFixation().changeSessionId() .and() .csrf().csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse());对应的Cookie属性将包含Set-Cookie: JSESSIONIDxxxx; Path/; Domainexample.com; HttpOnly; Secure; SameSiteLax4. 实战验证与排错指南4.1 验证步骤使用Chrome开发者工具检查Network标签页的Set-Cookie头在Application Cookies中确认各域名下的Cookie存储测试流程登录app1.example.com新标签页访问app2.example.com确认未自动携带会话信息4.2 常见问题排查现象可能原因解决方案Cookie不生效浏览器缓存未清除使用隐身窗口测试子域名无法共享Domain未设置为父域名检查.example.com的加点前缀HTTPS下失效Secure属性未设置配置server.ssl.enabledtrue5. 生产环境最佳实践会话存储分离将会话数据存储到Redis等外部存储而非内存spring.session.store-typeredis精细化路径控制serializer.setCookiePath(/app1); // 应用A serializer.setCookiePath(/app2); // 应用B监控配置通过Actuator端点检查会话配置GET /actuator/env/server.servlet.session.cookie防御性编程在拦截器中验证请求来源Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String expectedHost request.getServerName().contains(app1) ? app1 : app2; if(!request.getRequestURI().startsWith(/expectedHost)){ response.sendError(403); return false; } }在最近一次金融系统部署中我们采用子域名隔离Redis会话共享的方案成功支持了12个应用共享同一集群的场景。关键点在于提前在测试环境使用Selenium自动化脚本验证了所有Cookie隔离场景这比后期修复线上问题成本低得多。
1. 问题背景同一服务器多应用部署时的Cookie冲突上周在给客户部署一套微服务系统时遇到了一个典型的Cookie复用问题当两个Spring Boot应用部署在同一台服务器的不同端口时用户登录A系统后再访问B系统会自动带上A的会话信息导致权限混乱和异常跳转。这种问题在测试环境可能被忽视但上线后会造成严重的安全隐患。2. 核心原理Cookie的工作机制与域名绑定2.1 Cookie的默认作用域规则浏览器在处理Cookie时默认会根据以下三个要素判断是否发送域名匹配精确匹配或子域名Domain属性路径匹配Path属性协议一致Secure属性当这三个要素完全相同时即使服务端应用不同浏览器也会自动携带Cookie。在我们的案例中两个应用部署在应用Ahttp://server:8080/app1应用Bhttp://server:8081/app2由于未显式设置Domain和Path浏览器默认将Cookie绑定到server:8080和server:8081的根路径/导致跨应用传递。2.2 Spring Boot的默认Cookie配置通过调试发现Spring Session默认生成的Cookie具有以下特征JSESSIONIDxxxx; Path/; HttpOnly关键问题在于未设置Domain时浏览器自动绑定到当前访问的host:portPath/ 表示对所有子路径有效同名CookieJSESSIONID在多个应用间被覆盖3. 解决方案多维度隔离策略3.1 修改Cookie名称基础方案在application.properties中为每个应用设置唯一名称# 应用A配置 server.servlet.session.cookie.nameAPP1_SESSIONID # 应用B配置 server.servlet.session.cookie.nameAPP2_SESSIONID注意此方法仅解决Cookie覆盖问题未解决跨应用传递问题3.2 精确控制Cookie作用域推荐方案3.2.1 通过Nginx配置不同子域名upstream app1 { server localhost:8080; } upstream app2 { server localhost:8081; } server { listen 80; server_name app1.example.com; location / { proxy_pass http://app1; } } server { listen 80; server_name app2.example.com; location / { proxy_pass http://app2; } }3.2.2 应用层配置Configuration public class SessionConfig implements WebMvcConfigurer { Bean public CookieSerializer cookieSerializer() { DefaultCookieSerializer serializer new DefaultCookieSerializer(); serializer.setDomainName(example.com); serializer.setCookieName(APP_SPECIFIC_SESSION); serializer.setCookiePath(/); return serializer; } }3.3 高级防护SameSite属性配置在Spring Security配置中添加http.sessionManagement() .sessionFixation().changeSessionId() .and() .csrf().csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse());对应的Cookie属性将包含Set-Cookie: JSESSIONIDxxxx; Path/; Domainexample.com; HttpOnly; Secure; SameSiteLax4. 实战验证与排错指南4.1 验证步骤使用Chrome开发者工具检查Network标签页的Set-Cookie头在Application Cookies中确认各域名下的Cookie存储测试流程登录app1.example.com新标签页访问app2.example.com确认未自动携带会话信息4.2 常见问题排查现象可能原因解决方案Cookie不生效浏览器缓存未清除使用隐身窗口测试子域名无法共享Domain未设置为父域名检查.example.com的加点前缀HTTPS下失效Secure属性未设置配置server.ssl.enabledtrue5. 生产环境最佳实践会话存储分离将会话数据存储到Redis等外部存储而非内存spring.session.store-typeredis精细化路径控制serializer.setCookiePath(/app1); // 应用A serializer.setCookiePath(/app2); // 应用B监控配置通过Actuator端点检查会话配置GET /actuator/env/server.servlet.session.cookie防御性编程在拦截器中验证请求来源Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String expectedHost request.getServerName().contains(app1) ? app1 : app2; if(!request.getRequestURI().startsWith(/expectedHost)){ response.sendError(403); return false; } }在最近一次金融系统部署中我们采用子域名隔离Redis会话共享的方案成功支持了12个应用共享同一集群的场景。关键点在于提前在测试环境使用Selenium自动化脚本验证了所有Cookie隔离场景这比后期修复线上问题成本低得多。
