Exposing Page Metadata in Experience Editor

Experience Editor is, ultimately, the way that editors should interact with content in pages. I mean, as a developer, I quite like Content Editor for seeing my Sitecore content…

… but editors would typically prefer something a bit more visual, something a bit more WYSIWYG. That’s a large part of the value that Sitecore give – inline editing. It’s the point of a lot of content management systems.

That’s fine, and I’ve always found the Experience Editor fairly impressive in this regard – but what do you do about content that’s not visible in the page?

A good example is page metadata – so, canonical URLs, metadata tags, browser titles (for the browser tab), etc.. You might also have a ‘summary’ or ‘thumbnail’ to use in some form of content aggregation.

Well, in the SharePoint systems I used to work with, we’d use Edit Panels in the page – that is, areas of the page that would only be shown to editors, and that would let them set these bits of text. It worked pretty well, but it was a little… awkward.

How about if we presented a dialog instead?

Continue reading “Exposing Page Metadata in Experience Editor”

Advertisements
Exposing Page Metadata in Experience Editor

VS2017 – Turn off Lightweight Solution Loading

Note to self: I’d a solution where Project A referenced Project B. This had been fine and stable for some time, and then suddenly intellisence started warning that the namespace I needed from B was missing, and that I was missing a project reference. Except I wasn’t. And the solution would build without fault.

I found suggestions of deleting /obj and /.vs folders – which I did – but the fix came from turning off Lightweight Solution Loading. See : https://developercommunity.visualstudio.com/content/problem/98484/project-references-do-not-work.html

Clear Visual Studio bug.

VS2017 – Turn off Lightweight Solution Loading

Glass Mapper Model too deep. Potential lazy loading loop exception in a Custom LinkProvider

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”

Glass Mapper Model too deep. Potential lazy loading loop exception in a Custom LinkProvider

Hooking into Sitecore’s Logging

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.

Hooking into Sitecore’s Logging

Reset your Sitecore Admin password to ‘b’ when using SHA512 hashing

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”

Reset your Sitecore Admin password to ‘b’ when using SHA512 hashing

Password Strength Estimation with zxcvbn

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/

Password Strength Estimation with zxcvbn