ASP.NET主域与子域间Cookie及Session处理登录异常问题排查

让咱们一步步拆解你的问题，搞定跨域自动登录的难题：

首先明确：sub.mydomain.com和.sub.mydomain.com的Cookie其实差异不大，但得搞清楚它们的作用范围：

• .sub.mydomain.com是通配符子域Cookie，能被sub.mydomain.com以及它的所有下级子域（比如a.sub.mydomain.com）识别；
• sub.mydomain.com是精确子域Cookie，只能被sub.mydomain.com本身识别。

如果你的子应用只在sub.mydomain.com上运行，这两种Cookie其实都能正常生效，大概率不是登录失败的直接原因。不过如果你想严格精确匹配，可以在设置Cookie时明确指定domain=sub.mydomain.com（注意不要加开头的点），不同技术栈的设置方式举例：

• Java Spring：new Cookie("SESSIONID", sessionId).setDomain("sub.mydomain.com");
• Node.js Express：res.cookie('SESSIONID', sessionId, { domain: 'sub.mydomain.com' });

这个问题的根源基本是跨域请求的Session传递失效，咱们逐个排查：

1. 跨域请求未配置凭证允许 #

当主域mydomain.com调用子应用sub.mydomain.com的验证接口时，这属于跨域请求，浏览器默认不会携带Cookie（包括存储Session ID的Cookie），除非你完成两项配置：

• 子应用的CORS配置：必须指定允许的主域，同时开启凭证支持：

  // 以Node.js Express为例，其他技术栈逻辑类似
  app.use(cors({
    origin: 'https://mydomain.com', // 不能用*，必须指定具体主域
    credentials: true // 允许携带凭证
  }));
  

• 主域发起请求时携带凭证：比如用Axios请求时要加withCredentials: true：

  axios.post('https://sub.mydomain.com/api/verify', credentials, {
    withCredentials: true
  });
  

如果没做这些配置，第一次调用子应用接口时，子应用设置的Session ID Cookie根本不会被浏览器保存，第二次跳转自然拿不到Session。

2. Session存储未全局共享 #

如果子应用是多实例部署（比如用容器集群），但Session存在单个实例的内存里，那么第二次请求可能落到其他实例上，自然找不到之前设置的Session。解决方法是把Session存储换成全局共享的方案，比如：

• 用Redis存储Session（主流框架都有对应的Redis Session插件）；
• 改用JWT令牌替代服务器端Session（无状态方案，更适合跨域场景）。

3. 跳转逻辑的优化建议 #

你当前的流程是“主域调用子应用验证接口→设置Session→跳转子应用登录URL”，其实可以换成更可靠的令牌跳转方案，彻底绕开跨域Session传递的问题：

• 用户在主域登录验证通过后，生成一个加密的短期授权令牌（包含用户ID等必要信息）；
• 主域跳转到子应用的授权回调URL，比如https://sub.mydomain.com/auth/callback?token=加密后的令牌；
• 子应用验证令牌的有效性（用主域和子域共享的密钥解密），验证通过后直接创建用户Session、设置子域Cookie，然后跳转到默认页。

这个方案不需要跨域调用接口，稳定性更高，也避免了CORS配置的麻烦。

1. 检查子应用的CORS配置，确保允许主域请求并开启凭证支持；
2. 调整Cookie的domain为sub.mydomain.com（可选，但确保精确匹配）；
3. 把子应用的Session存储换成全局共享的（比如Redis）；
4. 尝试优化登录流程，采用令牌跳转的方式替代跨域接口调用。

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