YSOD

You don’t delete contents of your App_ConfigInclude. You just don’t, right? It’s not something people normally do. Well, I first did and then I forgot that I did while I was playing with cleaning up after TDS’s File Replacement. I then left for the day and the next day my local Sitecore sandbox wouldn’t behave. It wouldn’t accept a TDS deployment, it wouldn’t load the site, it wouldn’t let me in into the desktop.  The message I was given was very informative and  helpful. I am sure you like these as much as I do:

Here’s what I learned when I dug into it (I probably could have just re-installed the instance but then I wouldn’t have learned much).

Anti CSRF

Sitecore 6.6 introduced built-in CSRF protection. It’s a module that is attached in the Web.config:

<system.webServer>
    <modules runAllManagedModulesForAllRequests="true">
    ...
        <add name="SitecoreAntiCSRF"
             type="Sitecore.Security.AntiCsrf.SitecoreAntiCsrfModule, Sitecore.Security.AntiCsrf"/>
    </modules>
    ....
</system.webServer>


Revolutionize Your Business With Generative AI
From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business.  Our AI experts help you unlock GenAI’s full potential and drive growth.
Let’s Get Started
The way the module configures itself assumes there’s a specific XML node in the config file:
Settings.rootSettings = XElement.Parse(Factory.GetConfigNode("AntiCsrf").OuterXml);
if (Settings.rootSettings == null)
{
    Settings.rootSettings = XElement.Parse("<AntiCsrf [default stripped out for brevity] />");
}

Pay close attention to Factory.GetConfigNode("AntiCsrf") followed by .OuterXml
The module expects a default configuration. It can be empty but the configuration node had better be there. And the default configuration is (in my case it was) in the App_ConfigIncludeSitecore.AntiCsrf.config. Not having it there (remember I deleted all of it?) apparently renders Sitecore instance unresponsive. I am sure Sitecore would really miss all other config settings from that folder as well but CSRF is the only one required for the instance to properly start. Adding a plain simple <AntiCsrf/> to the Web.config is enough… At this point I remembered and also remembered that Sitecore had a Recycle Bin.
Thoughts
I feel like it would be more appropriate if the simple default configuration (the one that the code falls back to) was included in the Web.config along with the module. This way the extended version from App_ConfigInclude would become a nice-to-have . Another alternative would be to gracefully handle the potential NullReference case in the startup code. GetConfigNode() in Sitecore.Configuration.Factory could also follow the Null Object pattern and don’t default to returning null when not found by XPath but that’s another blog post. For the time being Assert.ArgumentNotNull is your best friend. And don’t delete contents of your App_ConfigInclude.
p.s. Last but not least, if an add-on module expects that certain things be present in the configuration  it should probably complain in plain English when it doesn’t see it.
🙂
				
				
				
				


					
Tags
BrainJocks jockstothecore Sitecore