Okay, so the context of the issue – I’ve been asked to do some custom URL mapping in Sitecore. The customer wants some of their pages to appear at URLs other than that defined by their site structure. There’s a good article about this here, and my URL resolver is working just fine.
However, as soon as I change my link provider to my new custom one, I get the following error:
Model too deep. Potential lazy loading loop.
Okay, what is this? Well, Glass is trying to save your bacon by preventing loops of loading models. If you exceed 8 levels of depth, then it throws a wobbly. This is a good thing. Continue reading “Glass Mapper Model too deep. Potential lazy loading loop exception in a Custom LinkProvider”
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…”
Following up my last post about Troy Hunt and breached passwords, I thought I’d look at something it mentioned – zxcvbn password strength estimation. Password strength estimators are, as a rule, crap. Usually it’s simply “is there a number, is there a capital”, etc., so passwords like “P@ssword1234” can come out as being ‘strong’, which is clearly wrong.
zxcvbn (awful name) attempts to make a smarter estimate of password strength. Basically, it looks at your password, and tries to estimate its strength based on appearances in dictionaries, structure, and entropy. It’ll then give an estimated “time to crack”, and tell you any matches that were achieved. For example (and neither of these are good passwords – score goes up to 4, and you want to get at least 3):
Yup, that’s pretty cool.
It’s available as a Nuget package (and is implemented in some form in most frameworks). The original zxcvbn was intended to run solely within the browser – but it still had a 0.5 Mb of dictionary files to download. That’s built into the assembly for the Nuget.
Testing a password – that’s simple:
var result = Zxcvbn.MatchPassword(“Squeamish Ossifrage”);
Neat. Worth considering if you’re implementing a password change or registration feature.
Bonus observation: http://gavinmiller.io/2016/a-tale-of-security-gone-wrong/
Troy Hunt has published the hashes of 306,000,000 passwords that have been breached. And exposed it as a web service.
This lets you tell a user if a given password has appeared in a breach. You send the service a hash of the password, and Troy’s web service responds if that hash has appeared in a breach.
Why is that useful? You can pro-actively inform users if their password has been breached (and recorded in haveibeenpawned) at either registration or login. You may want to block users from using that password, or you could just warn them.
Continue reading “Check Users Passwords during Registration/Login”
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”