Allow me to share some information from an article one of our senior specialists is currently in the process of writing about this error message, applicable for Kentico Xperience 13:
—
Administration and Live site are currently two separate applications (unlike in Portal Engine, where administration and Live site were one application), each of them has its own life cycle and authentication.
In some cases, this strict separation does not apply, specifically to PageBuilder and FormBuilder. In both cases, a live site is used to render the administrative UI using our endpoints (registered under https://mylivesite.com/cmsctx/*) and scripts (https://mylivesite.com/Kentico/scripts/*) on the live site. The reason why we approached this solution is prosaic - both builders have to run in the context of the Live site.
Each application handles authentication individually (administration uses ASP.NET membership and live site OWIN authentication). In case we render any of the builders or page preview in the administration, we already know that it runs in the context of a live site, but they lacked information about the currently logged in user in the administration. We decided to solve this problem by storing this information in a cookie.
So how the authentication of the Page builder frame for display purposes in administration actually works:
The administration application sends a request with a generated token to the live site system endpoint: https://livesite.com/Kentico.VirtualContext/Authenticate/*, live site verifies the validity of the token and issues a new token, where there is an information about the currently logged in user and saves this newly created token into the cookie under the name CMSVirtualContextIdentity.
When authentication is performed in Page builder, Page builder authenticates against this information in the cookie.
There are some issue with blocking 3rd party cookies: modern browsers try to prevent tracking of users, especially by blocking 3rd party cookies. Most browsers by default block only tracking of cookies. This means that our authentication cookie should work. But users can change this setting and therefore breaking the page builder's authentication.
At the same time, for example, Chrome blocks 3rd-party cookies also in its incognito mode. Safari uses its own heuristics.
There are multiple possible setups:
1. with the same domains:
The administration and live site applications use the same domain. The CMSVirtualContextIdentity cookie, which authenticates the live site in the page builder, is stored in the same cookie domain space as the administration. There is no 3rd-party cookie blocking applied, the page builder iframe has access to the cookie. For example:
Administration: localhost/admin
Live site: localhost/site
so:
- CMSVirtualContextIdentityis accessible from the page builder iframe
- this setup does not require HTTPS so it can be used in a dev environment
2 with the different domains
The administration and live site applications use different domains. There must be some additional steps taken in order to store the CMSVirtualContextIdentity cookie in the page builder frame. For example:
Administration: http(s)://admindomain.com
Live site: https://livesite.com
and therefore:
A) Proper domain setup
Live site must run on HTTPS because of the SameSite policy. SameSite mode is configured correctly
Browser cannot block 3rd-party cookies
B) Local development setup (ASP.NET Core only)
The page builder authentication can proceed without the CMSVirtualContextIdentityauthentication cookie. Kentico Xperience 13 is able to pass the authenticated user in a URL itself.
Although we are able to carry the authenticated user in the URL, it is not as secure as to store it in the cookie. Therefore we allow this simplification only for loopback domains in your DEV environment.
Kentico Xperience 13 leverages this simplification in the initial setup of the Xperience Dancing Goat Core sample site and the Blank Core site. Therefore the installed sites do not have to deal with various problems with cookies or invalid/self-signed certificates. How it works: ASP.NET Core sites can disable the cookie authentication in the dev environment via the DisableVirtualContextSecurityForLocalhostservice.
Once configured, the user information will be passed in all page builder requests in their URLs.
I hope it helps and gives you the idea how it works.