如何为 4.7.2 之前的 .Net Framework 设置 cookie 属性 Samesite = None（对于 4.5.2）

Question

根据 Google Chrome 最近的更新，它只允许具有属性的跨平台 cookie

sameSite=None

链接：https : //docs.microsoft.com/en-us/aspnet/samesite/system-web-samesite#net-versions-earlier-than-472

根据上图，Microsoft 不为低于 4.7.2 的版本提供此属性的内置支持。

因此，我们无法在服务器端创建 cookie 时设置它。

有什么可能的方法可以使用 SameSite 属性创建 cookie？

Answer 1

您可以通过使用 IIS URL 重写模块来实现此目的。这需要您在服务器本身上安装该模块，但这将为您提供我希望的解决方案。

<rewrite>
      <outboundRules>
        <clear />
        <rule name="Add SameSite" preCondition="No SameSite">
          <match serverVariable="RESPONSE_Set_Cookie" pattern=".*" negate="false" />
 
          <action type="Rewrite" value="{R:0}; SameSite=none;" />
          <conditions>
          </conditions>
        </rule>
        <preConditions>
          <preCondition name="No SameSite">
            <add input="{RESPONSE_Set_Cookie}" pattern="." />
            <add input="{RESPONSE_Set_Cookie}" pattern="; SameSite=none;" negate="true" />
          </preCondition>
        </preConditions>
      </outboundRules>
    </rewrite>

Answer 2

更新：

假设您安装了 IIS 的 URL Rewrite Extension 2.0（Azure App Services，nee Azure Websites，已经安装了这个），那么您应该查看@sreenath 的答案，因为该解决方案应该适用于大多数用户。

但是（在我的象牙塔内的一个巨大的自负泡沫中，我的特权地位）没有任何项目没有使用 .NET Framework 4.7.2 或更高版本，因为 .NET Framework 在过去 5 年多的时间里更新（Visual Studio 2013 年以后）在很大程度上是附加的和向后兼容的。因此，我强烈建议开发人员（尝试）先将他们的项目更新到 .NET Framework 4.7.2 或 4.8，然后再尝试使用 IIS 重写来设置SameSitecookie 参数等技巧。

我的原答案：

如何为 4.7.2 之前的 .Net Framework 设置 cookie 属性 Samesite = None（对于 4.5.2）

简单地说：你不能。

您链接的文章解释了原因（强调我的）：

Microsoft 不支持低于 4.7.2 的 .NET 版本用于编写相同站点 cookie 属性。我们还没有找到一种可靠的方法来：

• 确保根据浏览器版本正确写入属性。
• 拦截和调整旧框架版本上的身份验证和会话 cookie

唯一的解决方案是将您的项目升级到 .NET Framework 4.7.2 或更高版本。

但好消息是，从 .NET Framework 4.5 升级到 4.7.2 很容易，向后兼容性问题极少（如果有的话）。您甚至不必更改web.config文件中的任何内容（即，您仍然可以将 ASP.NET WebForms 4.5 与 .NET Framework 4.8 一起使用）。

您需要做的就是：

1. 进行新的 git 提交。
2. .csproj在记事本中打开您的文件。
3. 更改<TargetFrameworkVersion>v4.5.2</TargetFrameworkVersion>为<TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>
4. 节省。
5. 在 Visual Studio 中重新打开您的项目/解决方案，然后单击重建。

根据我的经验，您将遇到的唯一问题是：

• 需要刷新/重新安装 NuGet 包，因为 NuGet 确实不能轻松处理目标框架更改。这很容易修复（只需核对您的packages目录）。
• 具有特殊安装步骤的非 NuGet 依赖项（例如老式 WinForms 组件，ew）由于某种原因对特定的 .NET Framework 版本有严格的依赖性 - 在这种情况下，如果您的组件供应商没有，我会感到非常惊讶没有更新。

当然，我仍然会责备你的产品经理没有确保他们的项目在七年内保持正常工作（因为 .NET Framework 4.5.2 于 2013 年发布）。为什么没有设置 CI 管道来自动处理这个问题？