Sitecore Experience Explorer Tabs Are Mysteriously Empty

Experience Explorer Tabs Are Mysteriously Empty

I recently encountered an issue in a Standalone environment where the Sitecore Experience Explorer was completely empty. I had Presets in the tree, but all of tabs were empty. Somewhat of a big deal.

Empty Sitecore Experience Explorer tabs

A closer examination in the browser console revealed the following error: Failed to load resource: the server responded with a status of 403 ()

Opening up the offending URL to see if there was any further information, we could see the following message:

    "Message":"An error has occurred.",
    "ExceptionMessage":"The required anti-forgery form field \"__RequestVerificationToken\" is not present.",
    at System.Web.Helpers.AntiXsrf.TokenValidator.ValidateTokens(HttpContextBase httpContext, IIdentity identity, AntiForgeryToken sessionToken, AntiForgeryToken fieldToken)\r\n   
    at System.Web.Helpers.AntiXsrf.AntiForgeryWorker.Validate(HttpContextBase httpContext)\r\n   
    at Sitecore.Web.Http.Filters.ValidateHttpAntiForgeryTokenAttribute.OnAuthorization(HttpActionContext actionContext)"

Now if you work with Sitecore Forms or have been working in the Sitecore arena as a developer for any lengthy period of time, there's a very good chance you've seen that offending error before. And the majority of times it clears itself up after clearing cookies, restarting Sitecore, etc. Lots of ways to clear it up. But in my case, that just wasn't happening.

After a fair bit of searching online, and just shy of opening up a Sitecore support ticket, which I still plan on doing, I came across a few sites making now of the following setting.

<setting name="Sitecore.Web.IsAuthorizationBypassAllowed" value="true" />

After restarting Sitecore, my tabs in Explorer were populated with the appropriate information.

Sitecore Experience Explorer tabs

A word of warning though. So while adding this configuration setting in via a patch file, did indeed solve my problem there is a MAJOR security issue with this. And there's a reason why this setting is not actively broadcast as an option.

What this is effectively doing is bypassing the request verification process. Basically what Sitecore uses to ensure that requests through it's API are coming from a safe source. Therefore it should NEVER be deployed in a production environment with this setting intact unless you're in full control of all aspects of said environment (like a Standalone Dev environment).

What is unfortunate is that while this solution was originally found for Sitecore 9, it worked in Sitecore 10.1. So whatever is going on is still prevalent in the current version. If I hear back from Sitecore on this, I will be sure to update this article.

Hey, Developers!

We're on the look out for talented developers to join our team.

Think you have what it takes?

Meet David Austin

Development Team Lead


David is a decorated Development Team Lead with Sitecore Technology MVP and Coveo MVP awards, as well as Sitecore CDP & Personalize Certified. He's worked in IT for 25 years; everything ranging from Developer to Business Analyst to Group Lead helping manage everything from Intranet and Internet sites to facility management and application support. David is a dedicated family man who loves to spend time with his girls. He's also an avid photographer and loves to explore new places.

Connect with David