多域名联合登录需统一父域Cookie、集中式会话存储（如Redis）及前端Token协同验证。须设Domain=.example.com、用ProxyPassReverseCookieDomain重写、Spring Session+Redis共享会话，并规范JWT跳转与独立Cookie名。
apache 本身不管理会话，所谓“多域名联合登录的会话共享”，本质是多个域名（如 login.example.com、app.example.com、api.example.com）后端共用同一套用户认证体系，并在浏览器侧实现跨域可信会话识别。这不能靠 apache 的 sticky session 或负载均衡配置直接解决，而需从 cookie 隔离策略、会话存储统一、域名信任链三方面协同设计。
明确会话归属与作用域边界
默认情况下，各域名属于不同一级域（如 example.com 与 admin.example.com 属同域，但 app1.com 与 app2.com 是完全独立域），浏览器天然隔离 Cookie。要实现联合登录，必须让多个域名能读写同一个会话标识：
- 所有参与联合登录的域名必须属于同一父域，例如统一使用 .example.com（注意开头的点），这样 login.example.com、app.example.com、api.example.com 才能共享以 Domain=.example.com 设置的 Cookie
- 后端应用（如 Spring Boot 或 Tomcat）需显式设置 Session Cookie 的 Domain 属性为 .example.com，不能只设为 login.example.com
- Apache 作为反向代理时，需用 ProxyPassReverseCookieDomain 强制重写后端返回的 Set-Cookie 域名，例如：
ProxyPassReverseCookieDomain localhost .example.com
统一后端会话存储机制
仅靠 Cookie 共享不够——各应用后端必须能解析并验证同一个会话 ID。推荐放弃 Tomcat 默认内存 Session，改用集中式存储：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 接入 Redis：Spring Session + Redis 是主流方案，所有应用连接同一 Redis 实例，Session ID 由前端 Cookie 传递，后端统一查 Redis 获取用户身份
- 若用 Tomcat 原生集群，必须确保所有节点共享同一 Manager 配置（如
RedisStore），且<distributable></distributable>和<cluster></cluster>配置完整有效 - 避免依赖 JSESSIONID 路由（如 jvmRoute），因为多域名下请求可能被路由到任意后端，无法预设粘性
前端协同与登录跳转规范
联合登录不是自动发生的，需要明确流程控制：
- 主登录入口（如 login.example.com）完成认证后，应生成一个带签名的 Token（如 JWT），并写入 Domain=.example.com 的 Cookie，同时重定向至目标域名（如 app.example.com）
- 各业务域名的后端需校验该 Token（而非只认 JSESSIONID），校验通过即建立本地会话上下文
- Apache 可配合做简单跳转或 Header 注入，例如用
RewriteRule+Header set透传认证状态，但不建议在 Apache 层解析或签发 Token
规避常见污染与冲突
多个域名共用 Session Cookie 容易引发覆盖或误读：
- 为每个子应用单独配置 sessionCookiePath，例如 login.example.com 设为
/，app.example.com 设为/app/，避免路径级干扰 - 禁用
ProxyPreserveHost On（除非必要），防止 Host 头被错误透传导致后端日志或重定向异常 - 各应用使用唯一 Session Cookie 名称**，例如
LOGIN_SESSION_ID、APP_SESSION_ID，再由统一认证服务桥接映射，比强求共用 JSESSIONID 更安全可控
