The SameSite attribute on a cookie controls cross-domain policies and behavior. The attribute can be set by the server to let the browser know the desired policy when there’s a request to the cookie from the first-party (AdaptiveWork domain), or from a third-party integrated into AdaptiveWork, such as those used in custom panels and widgets.
One of the SameSite attributes used inAdaptiveWork is CZAUTHSV, and is used for authentication together with the domain clarizen.com.
Until Chrome 80, there were only two applicable values for the attribute – Lax and Strict. With only these options, AdaptiveWork did not set any value on the SameSite parameter, resulting in the cookie always being sent to the server, regardless of where it originated, the first-party or a third-party.
The upcoming change introduces a third value – None.
As a result, Chrome 80 will change the default behavior, and if the SameSite attribute is not set, the browser will set its value to Lax, which means that the cookie will be sent as part of the request originating in the first-party.
Setting the attribute to None (which preserves the current behavior) will result in earlier browser versions to behave as if the attribute is set to Strict.
How does this impactAdaptiveWork?
External websites integrated into AdaptiveWork, such as widgets and panels may encounter changes in their behavior.
What is AdaptiveWork doing to resolve possible changes in behavior?
AdaptiveWork is working on a solution, which will be transparent to end-users, and will work seamlessly on all supported browsers.
How can I make sure everything is working correctly?
We recommend testing all integrations and custom solutions used in your AdaptiveWork instance, especially custom panels, pages, and widgets.
You can also read this Chromium blog post for more info about the changes and how to test the updated solution.