Recently I was upgrading a site to Sitecore 8.2.1, and I received the following error:
Okay, WTF? There’s not a lot of information about this error, and I’d never seen it before. I ended up doing my usual trick – decompiling Sitecore to see what this method does. Here’s what I found…
…and the bit underlined in red set my “stupidity radar” screaming. This line is:
string database = SiteContext.GetSite(Settings.Preview.DefaultSite).SiteInfo.Database;
If GetSite() returns null, you’ll get a null reference exception, because they didn’t bother to check the returned variable before trying to use its ‘SiteInfo’ property.
It does offer a clue, though. Our upgraded system lacks a site called ‘website‘. That is, in our config, under the
<sites> node, there is no
<site ... > called ‘website‘. However, the
DefaultSite setting in Sitecore.config still had its default value of ‘website‘.
We changed it to the name of our site, and this error was resolved.
I was configuring a new Sitecore 8.1 instance. It’s a vanilla, straight-off-the-installer instance, and yet I noticed that the node’s request validation was off:
This did, at least, come with a comment above it:
If requestValidationMode attribute of httRuntime node is set to 2.0, Sitecore requires this setting to be set to “false” for Sitecore client to work and it shouldn’t be changed. You can however set ValidateRequest attribute in the @Page directive to “true” for your layout .aspx files.
This is bonkers. The default configuration for this site is to remove request validation on my brand new Sitecore instance on the off-chance I should want to configure it to use an older, non-default requestValidationMode. Instead, I should stumble across this comment in the web.config file and add the appropriate attribute to all the layouts of my solution. And someone thought that this was a good idea?
Even if I were upgrading and I did rely on the httpRuntime requestValidationMode being 2.0, I would prefer that this was set to true, with instructions for how I should handle it in the case of an upgrade.
Crazy. One to be aware of.
This is annoying misconfiguration I’ve come across a few times – tracing has been enabled on production systems.
Having tracing enabled allows an attacker to view the last 50 web requests made to the server, including information like Session ID values and the physical path to the requested files.
One can easily turn this off, though, by setting the
<trace> node of web.config…
However, you can do a bit more than that. I believe that this problem occurred on live sites because configuration files were promoted from development to production. To this end, you can set
localOnly="true" – this means that trace is only available on the local developer’s machine. This doesn’t substitute for disabling trace, but it does help reduce that risk.