特色的网站建设,买了域名怎么做网站,怀化网站优化联系方式,wordpress修改首页布局原文作者#xff1a;Sebastian Gingter原文链接#xff1a;https://reurl.cc/Dygrgd译者#xff1a;沙漠尽头的狼译文链接#xff1a;https://reurl.cc/1ZYNoQ本文是作者2019年的一篇分享#xff0c;里面的一些观点和使用的技术#xff0c;对我们现在的开发依然有效… 原文作者Sebastian Gingter原文链接https://reurl.cc/Dygrgd译者沙漠尽头的狼译文链接https://reurl.cc/1ZYNoQ本文是作者2019年的一篇分享里面的一些观点和使用的技术对我们现在的开发依然有效建议查看原文阅读对本文翻译如有疑问欢迎提PR[1]。首先好消息Google 将在 2020 年 2 月发布 Chrome 80时包括 Google 实施的“渐进式更好的 Cookie”(Incrementally better Cookies)这将使网络成为一个更安全的地方并有助于确保用户获得更好的隐私站长注现在是2022年4月28号Chrome已经发布了多个更新版本。坏消息是这个新实现是浏览器决定如何向服务器发送 cookie 的重大变化。首先如果您为 Web 应用程序和身份验证服务器使用单独的域那么 Chrome 中的这种更改很可能会破坏部分用户的会话体验。第二个问题是它还可能使您的部分用户无法再次正确注销您的系统。1. 首先这个 SameSite 是关于什么的Web 是一个非常开放的平台Cookie 是在大约 20 年前设计的以及 2011 年在 RFC 6265[2]中重新审视该设计时跨站请求伪造 (CSRF) 攻击和过度用户跟踪还不是什么大事。简而言之正常的 Cookie 规范说如果为特定域设置了 Cookie它将在浏览器发出的每个请求时带上Cookie发送到该域。无论您是否直接导航到该域如果浏览器只是从该域加载资源即图像向其发送 POST 请求或将其中的一部分嵌入到 iframe 中。但也许对于后一种可能性您不希望浏览器自动将用户会话 Cookie 发送到您的服务器因为这将允许任何网站在该用户的上下文中执行针对您的服务器的请求的 JavaScript而不会引起他们的注意。为了防止这种情况发生 SameSite cookie 规范[3] 是在 2016 年起草的。它让您可以更好地控制何时应该或不应该发送 cookie当您设置 cookie 时您现在可以为每个 cookie 明确指定浏览器何时应将其添加到请求。为此当浏览器位于您自己的域中时它引入了同站点 cookie 的概念而当浏览器在不同域中导航但向您的域发送请求时它引入了跨站点 cookie 的概念。为了向后兼容相同站点 cookie 的默认设置并没有改变以前的行为。您必须选择加入该新功能并明确设置您的 cookie SameSiteLax 或 SameSiteStrict 使其更安全。这已在 .NET Framework(包括.NET CORE) 和所有常见浏览器中实现。Lax 意味着cookie 将在初始导航时发送到服务器 Strict 意味着 cookie 只会在您已经在该域上时发送即初始导航后的第二个请求。遗憾的是这项新功能的采用速度很慢根据 2019 年 3 月 Chrome 的遥测数据 【来源[4] 】全球范围内 Chrome 上处理的所有 cookie 中只有 0.1% 使用 SameSite 标志。谷歌决定推动采用该功能。为了强制执行他们决定更改世界上最常用的浏览器的默认设置Chrome 80 将 必须 指定一个新的设置 SameSiteNone 来保留处理 cookie 的旧方式如果您像旧规范建议的那样省略 SameSite 字段它将 cookie 视为使用 SameSiteLax.请注意该设置 SameSiteNone 仅在 cookie 也被标记为 Secure 并需要 HTTPS 连接时才有效。更新 如果您想了解有关 SameSite cookie 的更多背景信息有一篇包含 所有细节的新文章[5]。2. 这对我有影响吗如果是怎么做如果您有一个单页面 Web 应用程序 (SPA)它针对托管在不同域上的身份提供者IdP例如 IdentityServer 4[6]进行身份验证并且该应用程序使用所谓的静默令牌刷新您就会受到影响。登录 IdP 时它会为您的用户设置一个会话 cookie该 cookie 来自 IdP 域。在身份验证流程结束时来自不同域的应用程序会收到某种访问令牌这些令牌通常不会很长时间。当该令牌过期时应用程序将无法再访问资源服务器 (API)如果每次发生这种情况时用户都必须重新登录这将是非常糟糕的用户体验。为防止这种情况您可以使用静默令牌刷新。在这种情况下应用程序会创建一个用户不可见的 iframe并在该 iframe 中再次启动身份验证过程。IdP 的网站在 iframe 中加载如果浏览器沿 IdP 发送会话 cookie则识别用户并发出新令牌。现在 iframe 存在于托管在应用程序域中的 SPA 中其内容来自 IdP 域。如果 cookie 明确指出 SameSiteNoneChrome 80 只会将该 cookie 从 iframe 发送到 IdP这被认为是跨站点请求。如果不是这种情况您的静默令牌刷新将在 2 月 Chrome 80 发布时中断。还有其他情况可能会给您带来问题首先如果您在 Web 应用程序或网站中嵌入源自另一个域的元素例如视频的自动播放设置并且这些需要 cookie 才能正常运行这些也会需要设置 SameSite 策略。如果您的应用程序需要从依赖于 cookie 身份验证的浏览器请求第 3 方 API这同样适用。注意 显然您只能更改您自己的服务器关于cookie设置的cookie 行为。如果您碰巧使用了不受您控制的其他域中的元素您需要联系第 3 方并在出现问题时要求他们更改 cookie。3. 好的我将更改我的代码并将 SameSite 设置为 None。我现在可以了对吧不幸的是Safari 有一个“错误”[7]。此错误导致 Safari 无法将新引入的值 None 识别为 SameSite 设置的有效值。当 Safari 遇到无效值时它会将 SameSiteStrict 当作已指定的设置并且不会将会话 cookie 发送到 IdP。此错误已在 iOS 13 和 macOS 10.15 Catalina 上的 Safari 13 中修复但不会向后移植到 macOS 10.14 Mojave 和 iOS 12它们仍然拥有非常大的用户群。所以我们现在陷入了两难境地要么我们忽略 SameSite 策略我们的 Chrome 用户无法进行静默刷新要么我们设置 SameSiteNone 并锁定 iPhone、iPad 和 Mac 用户无法更新或者旧设备无法更新到最新版本的 iOS 和 macOS。4. 有没有办法确定我受到影响幸运的是是的。如果您已经设置 SameSiteNone您可能已经注意到您的应用程序或网站在 iOS 12 和 macOS 10.4 上的 Safari 中无法正常工作。如果没有请确保在这些版本的 Safari 中测试您的应用程序或网站。如果您根本不设置 SameSite 值您只需在 Chrome 中打开您的应用程序并打开开发人员工具即可。您将看到以下警告A cookie associated with a cross-site resource at {cookie domain} was set without the SameSite attribute.
A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSiteNone and Secure.
You can review cookies in developer tools under ApplicationStorageCookies and see more details at
https://www.chromestatus.com/feature/5088147346030592 and
https://www.chromestatus.com/feature/5633521622188032.如果您已经设置 SameSiteNone 但忘了设置 Secure 标志您将收到以下警告A cookie associated with a resource at {cookie domain} was set with SameSiteNone but without Secure.
A future release of Chrome will only deliver cookies marked SameSiteNone if they are also marked Secure.
You can review cookies in developer tools under ApplicationStorageCookies and
see more details at https://www.chromestatus.com/feature/5633521622188032.5. 那么我该如何真正解决这个问题我需要 Chrome 和 Safari 正常使用。我们也就是我的同事 Boris Wilhelms 和我自己对该主题进行了一些研究并找到且验证了解决方案。微软的 Barry Dorrans也有一篇 关于这个问题的好博文[8]。该解决方案并不美观遗憾的是需要在服务器端进行浏览器嗅探但这是一个简单的解决方案在过去的几周里我们已经在我们的几个客户项目中成功实现了这一点。要解决这个问题我们首先需要确保需要通过跨站点请求传输的 cookie例如我们的会话 cookie设置为 SameSiteNone 和 Secure。我们需要在项目代码中找到该 cookie 的选项并进行相应调整。这解决了 Chrome 的问题并引入了 Safari 问题。然后我们将以下类和代码片段添加到项目中。这会在 ASP.NET Core Web 应用程序中添加和配置 cookie 策略。此策略将检查是否设置了 cookie 为 SameSiteNone 。如果是这种情况它将检查浏览器的用户代理并确定这是否是一个浏览器的设置有问题比如我们受影响的 Safari 版本。如果也是这种情况它会将 cookies SameSite 值设置为unspecified(未指定)这反过来将完全阻止设置 SameSite从而为这些浏览器重新创建当前默认行为。请注意此处提供的解决方案适用于 .NET Core。对于完整的基于 .NET Framework 的项目您需要查看Barry Dorran 的帖子[9]中指定的版本之一 。5.1 要添加到项目中的类using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Http;namespace Microsoft.Extensions.DependencyInjection
{public static class SameSiteCookiesServiceCollectionExtensions{/// summary/// -1 defines the unspecified value, which tells ASPNET Core to NOT/// send the SameSite attribute. With ASPNET Core 3.1 the/// seealso crefSameSiteMode / enum will have a definition for/// Unspecified./// /summaryprivate const SameSiteMode Unspecified (SameSiteMode) (-1);/// summary/// Configures a cookie policy to properly set the SameSite attribute/// for Browsers that handle unknown values as Strict. Ensure that you/// add the seealso crefMicrosoft.AspNetCore.CookiePolicy.CookiePolicyMiddleware //// into the pipeline before sending any cookies!/// /summary/// remarks/// Minimum ASPNET Core Version required for this code:/// - 2.1.14/// - 2.2.8/// - 3.0.1/// - 3.1.0-preview1/// Starting with version 80 of Chrome (to be released in February 2020)/// cookies with NO SameSite attribute are treated as SameSiteLax./// In order to always get the cookies send they need to be set to/// SameSiteNone. But since the current standard only defines Lax and/// Strict as valid values there are some browsers that treat invalid/// values as SameSiteStrict. We therefore need to check the browser/// and either send SameSiteNone or prevent the sending of SameSiteNone./// Relevant links:/// - https://tools.ietf.org/html/draft-west-first-party-cookies-07#section-4.1/// - https://tools.ietf.org/html/draft-west-cookie-incrementalism-00/// - https://www.chromium.org/updates/same-site/// - https://devblogs.microsoft.com/aspnet/upcoming-samesite-cookie-changes-in-asp-net-and-asp-net-core//// - https://bugs.webkit.org/show_bug.cgi?id198181/// /remarks/// param nameservicesThe service collection to register see crefCookiePolicyOptions / into./param/// returnsThe modified see crefIServiceCollection /./returnspublic static IServiceCollection ConfigureNonBreakingSameSiteCookies(this IServiceCollection services){services.ConfigureCookiePolicyOptions(options {options.MinimumSameSitePolicy Unspecified;options.OnAppendCookie cookieContext CheckSameSite(cookieContext.Context, cookieContext.CookieOptions);options.OnDeleteCookie cookieContext CheckSameSite(cookieContext.Context, cookieContext.CookieOptions);});return services;}private static void CheckSameSite(HttpContext httpContext, CookieOptions options){if (options.SameSite SameSiteMode.None){var userAgent httpContext.Request.Headers[User-Agent].ToString();if (DisallowsSameSiteNone(userAgent)){options.SameSite Unspecified;}}}/// summary/// Checks if the UserAgent is known to interpret an unknown value as Strict./// For those the see crefCookieOptions.SameSite / property should be/// set to see crefUnspecified /./// /summary/// remarks/// This code is taken from Microsoft:/// https://devblogs.microsoft.com/aspnet/upcoming-samesite-cookie-changes-in-asp-net-and-asp-net-core//// /remarks/// param nameuserAgentThe user agent string to check./param/// returnsWhether the specified user agent (browser) accepts SameSiteNone or not./returnsprivate static bool DisallowsSameSiteNone(string userAgent){// Cover all iOS based browsers here. This includes:// - Safari on iOS 12 for iPhone, iPod Touch, iPad// - WkWebview on iOS 12 for iPhone, iPod Touch, iPad// - Chrome on iOS 12 for iPhone, iPod Touch, iPad// All of which are broken by SameSiteNone, because they use the// iOS networking stack.// Notes from Thinktecture:// Regarding https://caniuse.com/#searchsamesite iOS versions lower// than 12 are not supporting SameSite at all. Starting with version 13// unknown values are NOT treated as strict anymore. Therefore we only// need to check version 12.if (userAgent.Contains(CPU iPhone OS 12)|| userAgent.Contains(iPad; CPU OS 12)){return true;}// Cover Mac OS X based browsers that use the Mac OS networking stack.// This includes:// - Safari on Mac OS X.// This does not include:// - Chrome on Mac OS X// because they do not use the Mac OS networking stack.// Notes from Thinktecture:// Regarding https://caniuse.com/#searchsamesite MacOS X versions lower// than 10.14 are not supporting SameSite at all. Starting with version// 10.15 unknown values are NOT treated as strict anymore. Therefore we// only need to check version 10.14.if (userAgent.Contains(Safari) userAgent.Contains(Macintosh; Intel Mac OS X 10_14) userAgent.Contains(Version/)){return true;}// Cover Chrome 50-69, because some versions are broken by SameSiteNone// and none in this range require it.// Note: this covers some pre-Chromium Edge versions,// but pre-Chromium Edge does not require SameSiteNone.// Notes from Thinktecture:// We can not validate this assumption, but we trust Microsofts// evaluation. And overall not sending a SameSite value equals to the same// behavior as SameSiteNone for these old versions anyways.if (userAgent.Contains(Chrome/5) || userAgent.Contains(Chrome/6)){return true;}return false;}}
}5.2 配置和启用 cookie 策略要使用此 cookie 策略您需要将以下内容添加到您的启动代码中public void ConfigureServices(IServiceCollection services)
{// Add thisservices.ConfigureNonBreakingSameSiteCookies();
}public void Configure(IApplicationBuilder app)
{// Add this before any other middleware that might write cookiesapp.UseCookiePolicy();// This will write cookies, so make sure its after the cookie policyapp.UseAuthentication();
}6. 好的。我现在完成了吗除了彻底的测试特别是在 Chrome 79 中激活了“默认 cookie 的 SameSite”标志以及 macOS 和 iOS 上受影响的 Safari 版本是的你现在应该没事了。要在 Chrome 79 中进行测试请导航到 chrome://flags、搜索 samesite 并启用该 SameSite by default cookies 标志。重新启动浏览器您可以立即测试即将发生的更改。严肃的说确保您的静默刷新 - 或者通常是需要 cookie 的跨站点请求 - 仍然可以在这些设备和浏览器上运行。7. 我不能简单地等待我的身份验证服务器供应商为我解决这个问题吗这是不太可能的。在我们这里的具体示例中实际上管理 cookie 的不是 IdentityServer 本身。IdentityServer 依赖于 ASP.NET Core 框架的内置身份验证系统这是管理会话 cookie 的地方。虽然 ASP.NET Core 框架已更新以支持新 SameSite 值 None 和技术设置 Unspecified 不发送 SameSite 但微软表示[10] 他们不能直接在 ASP.NET Core 中引入用户代理嗅探。所以这真的取决于你和你现有的项目。8. 总结Chrome 将很快2020 年 2 月更改其处理 cookie 的默认行为。将来它将默认 SameSite 被明确设置为None标志 和 Secure 标志设置以允许将 cookie 添加到某些跨站点请求。如果你这样做常见版本的 Safari 就会对此感到厌烦。为确保所有浏览器都满意您将所有受影响的 cookie 设置为 Secure 和 SameSiteNone然后添加一个 cookie 策略如上所示的代码该策略可以覆盖这些设置并再次为无法对 None 正确解释该值的浏览器删除SameSite标志.参考资料[1]提PR: https://github.com/dotnet9/Assets.Dotnet9/pulls[2]RFC 6265: https://tools.ietf.org/html/rfc6265/[3]SameSite cookie 规范: https://tools.ietf.org/html/draft-west-first-party-cookies-07/[4]来源: https://tools.ietf.org/html/draft-west-http-state-tokens-00#section-1.2/[5]所有细节的新文章: https://www.thinktecture.com/en/identityserver/samesite-cookies-in-a-nutshell/[6]IdentityServer 4: https://identityserver.io/[7]有一个“错误”: https://bugs.webkit.org/show_bug.cgi?id198181[8]关于这个问题的好博文: https://devblogs.microsoft.com/aspnet/upcoming-samesite-cookie-changes-in-asp-net-and-asp-net-core/[9]Barry Dorran 的帖子: https://devblogs.microsoft.com/aspnet/upcoming-samesite-cookie-changes-in-asp-net-and-asp-net-core/[10]微软表示: https://devblogs.microsoft.com/aspnet/upcoming-samesite-cookie-changes-in-asp-net-and-asp-net-core/
