Back-End Development

A Note about App_ConfigInclude and Anti CSRF

Keyboard Abstract@1x.jpg


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).


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

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

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.


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.


About the Author

As a Sitecore MVP, Brian spends most of his time consulting and architecting software solutions for enterprise-level Sitecore projects.

More from this Author

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe to the Weekly Blog Digest:

Sign Up