Sitecore uses Log4Net for it’s logging framework, so it comes with a whole slew of different ‘appenders’, suitable for logging to various repositories. That’s nice, but what if there’s a target you want to use that doesn’t exist?
Well, you can override the SitecoreLogFileAppender and write your own output:
What else could you do with this? Well, writing to App Insights seems like a good bet.
Okay, this this relates to my recent post on password hashing in Sitecore, and why we should move away from SHA1. Let’s say you’ve decided to use SHA512 for a brand new instance like Sitecore recommend…
When you create a new website, you must change the weak default hash algorithm (SHA1) that is used to encrypt user passwords to a stronger algorithm.
To change the hash algorithm:
- Open the web.config file and in the <membership> node, set the hashAlgorithmType setting to the appropriate value. We recommend SHA512.
Okay, funky, but how do I make the existing admin’s password work? Continue reading “Reset your Sitecore Admin password to ‘b’ when using SHA512 hashing”
Nope, not cannabis, nor potato, but rather this:
Yup, password hashes in Sitecore. Unfortunately, they’re not all that secure – but they can be. Continue reading “Hashing for fun and profit…”
So, you’re doing an upgrade. You copy the live system, run through the upgrade, and test it, before repeating the ‘upgrade’ bit during content freeze with the latest data. So far, so normal; it’s a sensible way to check your system before the big update.
Picture this, if you will. You’ve done the upgrade with a snapshot of the data. It’s taken months. You tested, fixed, tested, fixed, and you’re happy to start the content freeze, run the express migration tool, and go live. So you run the Express Migration tool 2.0, and then try logging in as Admin to check it worked…
Continue reading “Sitecore Express Upgrade Tool 2.0 Issue”
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 asked the other day, where do you sign up for Sitecore’s security notifications? Well, I get them – but I don’t think I ever did. I suspect it was just part of doing their developer’s course.
However, you can apparently do this here: http://www.sitecore.net/landing/xc/2016/xc-ops-sitecore-security-notifications
I’ve not tried it, though.
I was working at a customer recently who’s Sitecore instance wasn’t accessible over HTTPS. It was a single server, and the site itself was working just fine over HTTPS, so that begged the question – why?
The error we were getting was:
Sitecore.Context.ContentDatabase returns null.
We were using HTTPS, and it’s worth noting that rather than redirecting all HTTP traffic to HTTPS with IIS, they were using C# code and a Response.Redirect() call in their page itself, which is… unusual. It also means that HTTP traffic to Sitecore shell is not redirected – the content page layout isn’t loaded, so their redirect wouldn’t happen.
Eventually, I found the following in a patch file:
Interesting. Shell and login were being tied to port 80 – but HTTPS uses 443.
I removed this patch, and suddenly Sitecore was available over HTTPS again.