Note: This page will be updated as soon as new troubleshooting information is available.
With version 80, Google Chrome implemented the changes the IETF has proposed for the SameSite Cookie attribute. These are:
To comply to these changes, Microsoft ASP.NET emits a SameSite cookie header when HttpCookie.SameSite value is None. As part of this change, FormsAuth and SessionState cookies will also be issued with SameSite = Lax instead of the previous default value None.
Full documentation on the changes in ASP.NET can be found in this document: Work with SameSite cookies in ASP.NET.
A bug in Chrome affects large PDFs with restricted access when SameSite = Lax for forms authentication. See https://www.epinova.se/en/blog/issues-with-pdf-preview-for-secured-pdfs-in-google-chrome-due-to-.net-security-patch/
The new policy should work for most websites and cookies. Websites that cannot comply with the requirements of Lax have to change the default values. An example of a limitation with Lax is that it is not possible to iframe the site under another domain and still use cookie-based features such as authentication and session state.
Note: Older browsers might not support SameSite or implement a different behaviour on SameSite.
Configuring the built-in anti-forgery used in Episerver user interface (requires EPiServer.CMS.Core 11.15):
options.CookieSameSiteType = SameSiteType.None;
options.CookieRequireSSL = true;
Configuring forms authentication to using None and HTTPS:
<forms cookieSameSite="None" requireSSL="true" />
Configuring session state to using None:
<sessionState cookieSameSite="None" cookieless="false" timeout="360">
Configuring the default for all cookies that do not explicitly use SameSite:
<httpCookies sameSite="None" requireSSL="true" />
Revert to the previous behaviour of not sending SameSite = None to browsers:
<add key="aspnet:SuppressSameSiteNone" value="true" />
Last updated: Feb 19, 2020