There are some quite big changes in Chrome 80, and later on in Firefox/Edge(With Chromium), that affects cookies.
Some good litterature here:
This will break quite a few flows that might not be Episerver specific, but a few things Episerver uses are also affected. For example Episerver Commerce relies on anonymous identification and the anonymous identication module does not seem to be updated to set the SameSite cookie attribute, so will potentially break in some browsers affecting carts and so on. Also it seems using the content delivery api could also be affected depending on how you use it.
I tried both the Chromium beta channel and also enabled the SameSite feature flags in current Chrome browser and there is quite a few warnings in the developer console about cookies being blocked which will affect various features in Episerver and its addons is my guess.
So my question to Episerver and the community is: what have people done to mitigate this? Have you experienced any breaking stuff in your current solutions when using the beta versions of Chrome?
Have you tried adding the following to Web.config? It will make all HttpCookie instances default to SameSite=Lax (or Strict) in the response.
<httpCookies sameSite="Lax" />
If you use OWIN cookie authentication middleware, it needs to use a CookieManager that adheres to the above configuration. Like the following.
CookieManager = new SystemWebChunkingCookieManager()
yes I know how to adjust various things via configs in .net 4.7.2, but there are so many gotchas, for example:
Setting SameSite=Lax will break openid connect flows which uses response type form (Azure AD for example)
Setting SameSite=None will fix openid connect flows, but will not work in safari on macos and ios, unless it is the newest version of macos and ios. So you need browser sniffing, which Microsoft and Google recommends, and others recommend double cookie strategy (Auth0).
Also Episerver Commerce relies on the anonymous identification module, which also does not handle SameSite so carts will most likely break in some scenarios. Episervers anti forgery cookie also does not set SameSite and the list goes on.
We are going with Microsofts recommendation here: https://devblogs.microsoft.com/aspnet/upcoming-samesite-cookie-changes-in-asp-net-and-asp-net-core/
But that doesn't fix the anon cookie for example, so I sure hope Episerver have tested this. Other things could be broken, but these are the things I have discovered.
Did you reach out Episerver support for this case?
My post was about making ASP.Net and OWIN set the SameSite value in the cookies. The settings I posted adds SameSite on all cookies: .ASPXANONYMOUS, __RequestVerificationToken as well as all OWIN authentication cookies.
I haven't yet tested SameSite with OpenID or other external login flows.
Assuming that non-OWIN cookies, like the anonymous cookie and the CSRF cookies, can have same SameSite mode for all browsers, you could set a default in web.config (covering non-OWIN cookies) and use that SameSiteCookieManager (from the link you posted). This assumes that the SameSiteCookieManager is changed to sniff the user agent and change/override the SameSite mode of OWIN cookies, before calling the inner cookie manager.
Just want to chime in to say that Thomas's recommendation for specifying the CookieManager in both CMS and CommerceManager Startup.cs files worked for me. 👍