ASP.NET Web应用仅在Chrome 66.0.3359.181中Session重置问题求助

结合你的场景（仅部署环境回发后Session重置、本地正常），这个问题几乎可以确定和Chrome 66引入的Cookie行为变更有关，具体是以下几个特性在起作用：

• SameSite Cookie 规范的强制落地
  Chrome 66是首个开始强制推行SameSite Cookie标准的正式版本。如果你的ASP.NET应用没有显式设置Session Cookie的SameSite属性，Chrome会默认将其标记为SameSite=Lax。在部署环境中，如果存在跨站回发、反向代理（比如负载均衡、CDN）或者iframe嵌入的情况，Lax模式会阻止Cookie在非GET请求的跨站场景中传递，导致回发时SessionID丢失，Session被重置。而本地环境通常是同源请求（比如localhost），不会触发这个限制。

• Secure Cookie 传输的严格校验
  若你的部署环境使用HTTPS，ASP.NET会自动为Session Cookie添加Secure属性（仅允许HTTPS传输）。Chrome 66增强了对Secure Cookie的校验逻辑：如果部署环境的HTTPS配置存在问题（比如证书不被信任、混合内容），Chrome会拒绝保存或传输该Cookie，最终导致SessionID丢失。本地环境如果用HTTP运行，不会触发Secure校验，因此正常。

• 第三方Cookie 默认拦截的初步测试
  Chrome 66开始小范围测试第三方Cookie拦截机制，如果你的应用被嵌入到其他站点的iframe中，或者依赖第三方资源的跨域请求，Chrome会默认拦截Session Cookie的传递，引发Session重置。本地环境通常没有这种跨域嵌入场景，所以不受影响。

要确定两台电脑的Chrome配置差异，可以通过以下几种方式：

• 直接对比Cookie核心设置
  打开Chrome，输入chrome://settings/content/cookies，分别查看两台电脑的以下选项：

  • 是否开启了「阻止第三方Cookie」
  • 是否将你的部署站点添加到「允许的站点」列表
  • 是否开启了「仅在您使用安全连接时才允许设置Cookie」

• 检查实验性特性开关
  输入chrome://flags/，搜索以下和Cookie相关的标志，对比两台电脑的状态（启用/禁用/默认）：

  • SameSite by default cookies
  • Cookies without SameSite must be secure
    这两个标志在Chrome 66中是刚推出的实验性特性，不同的设置会直接影响Cookie的处理逻辑。

• 用开发者工具分析Cookie属性
  在两台电脑上分别访问部署环境的应用，打开F12开发者工具，切换到「Application」标签页，展开「Cookies」查看SessionID Cookie的属性：

  • 对比SameSite、Secure、Domain字段的值
  • 检查Cookie是否存在、是否被标记为「HttpOnly」

• 查看组策略与配置文件差异
  如果是企业环境的Chrome，输入chrome://policy/查看是否有强制的Cookie相关策略；也可以通过chrome://version/找到Chrome的配置文件路径，对比两台电脑的配置文件（注意备份后操作）。

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