ASP.NET Core 2.0谷歌多账户认证后无法获取Cookie-based TempData

这看起来不是你的操作失误，更可能是ASP.NET Core 2.0 TempData默认配置与Chrome多账户认证流程之间的兼容性问题，甚至是一个框架潜在的边缘场景Bug。结合你描述的现象，我来拆解下可能的原因和解决思路：

核心现象背后的逻辑 #

首先明确几个关键点：

• ASP.NET Core 2.0默认的Cookie-based TempData，依赖CookieTempDataProvider处理数据的存储、读取和自动清理（读取后标记删除，下一次请求时清除对应Cookie）。
• 你提到Chrome中Cookie明明存在，但回调时TempData取不到键，随后Cookie消失——这说明CookieTempDataProvider在尝试读取时没有找到预期的键，触发了默认的清理逻辑，把对应的Cookie删掉了。
• Edge中正常、Chrome单账户自动登录正常，只有多账户选择时出问题，说明问题和Chrome的多账户跳转流程或Cookie策略强相关。

可能的根源 #

1. Chrome多账户场景下的Cookie跨域传递限制
   当用户选择谷歌账户时，会经历“你的站点→谷歌账户选择页→你的回调地址”的跳转流程，这比单账户自动登录多了一次跨域跳转。ASP.NET Core 2.0默认给TempData Cookie设置了SameSite=Lax属性，这个属性在跨域跳转时，Chrome可能会限制Cookie的携带（尤其是多账户隔离环境下），导致回调请求中没有带上TempData Cookie，或者携带的Cookie无法被框架正确识别。而Edge的Cookie策略在这个场景下更宽松，所以没有出现问题。

2. ASP.NET Core 2.0与1.1的TempData Cookie配置差异
   ASP.NET Core 1.1中你手动配置的TempData Cookie，可能没有设置SameSite属性，而2.0默认添加了这个配置。这种默认配置的变化，刚好在Chrome多账户的特殊跳转场景下触发了兼容性问题。

验证与解决思路 #

1. 调整TempData Cookie的SameSite配置 #

手动修改TempData Cookie的SameSite属性为None（注意必须配合HTTPS使用，Chrome要求SameSite=None的Cookie必须是安全的），看看是否能解决跨域跳转时的Cookie携带问题：

services.Configure<CookieTempDataProviderOptions>(options =>
{
    options.Cookie.Name = ".AspNetCore.TempData";
    options.Cookie.SameSite = SameSiteMode.None;
    options.Cookie.SecurePolicy = CookieSecurePolicy.Always;
    options.Cookie.HttpOnly = true;
});

2. 切换为Session-based TempData #

如果Cookie方式的兼容性问题难以解决，可以改用Session存储TempData，数据存在服务器端，完全不受浏览器Cookie策略的影响：

• 首先注册Session服务和Session-based TempData提供器：

services.AddSession(options =>
{
    // 配置Session的过期时间等参数
    options.IdleTimeout = TimeSpan.FromMinutes(30);
    options.Cookie.HttpOnly = true;
});
services.AddMvc().AddSessionStateTempDataProvider();

• 然后在Configure方法中启用Session（要放在UseMvc之前）：

app.UseSession();
app.UseMvc();

3. 调试Cookie传递过程 #

用Chrome开发者工具的Network面板，查看从谷歌账户选择页跳转到你的回调地址的请求，检查请求头中是否携带了TempData的Cookie。如果没有携带，基本可以确认是Chrome的Cookie策略限制导致的，调整SameSite配置就能解决。

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