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>


Choosing a Global Software Development Partner to Accelerate Your Digital Strategy
To be successful and outpace the competition, you need a software development partner that excels in exactly the type of digital projects you are now faced with accelerating, and in the most cost effective and optimized way possible.
Get the Guide
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 configuration CSRF jockstothecore Sitecore