Notes on an annoying misconfiguration

I spent a while banging my head against an issue on a client’s site last week. Having finally worked out the subtle misconfiguration of that was causing the bug, I thought I should write it down in case anyone else ever suffers the same problem. I figure if I write this down in enough detail, maybe the next person who suffers a related problem won’t have to spend as much time Googling as I did…


The client reported that on their v6.6 site the Content Editor’s Preview button was showing the wrong page, but that the rest of the Content Editor and the Page Editor were working ok. When I investigated in more detail, I found that the Publishing Preview button

Preview Button

was showing the site’s homepage rather than the page you had tried to preview. However it was only doing this for some pages on the site. Any page where the “Require Login” security setting had been applied

Require Login

suffered from the issue. But any page which this was not applied to did not show the problem, and would preview fine. Remove this security setting, and the problem went away. Add it to any page and the problem would appear for that page.

Looking in the Sitecore Logs, each attempt to preview a page that showed the wrong result generated an error message. But not a massively helpful one:

4916 03:37:08 ERROR Item could not be found from query string. [ID is "{9F12B247-9671-45E4-9F15-F27D92B74AF2}".]


The “could not be found” bit lead me off down a blind alley for a while checking to see if the item wasn’t missing from databases, or if the querystring ID for the preview page matched the item ID of the thing that was being clicked on in Content Editor. Searching Stack Overflow, the Sitecore Developer Network Forums and other places gave some clues about this, but I didn’t find anything describing the particular problem I was seeing. The issue turns out to be down to security configuration:

The <site/> config entry for the url being browsed had the attribute domain="extranet" in it. Reading around on the internet, when you click the Preview button, Sitecore tries to load the item you selected using the “<domain>\anonymous” account – where <domain> is the value of the domain attribute from your configuration.

So in this case, Sitecore was trying to run the preview as “extranet\anonymous” – which is exactly the security right that we have denied by clicking “Require Login”:

Security Details

So the log error really means “I can’t load that item because access is denied”. For reasons best known to themselves, the developers who wrote this bit of code seem to have decided that if you can’t load an item you should fall back to the homepage item instead of warning the user what’s happened.

Changing the domain attribute’s value to the correct “sitecore” security domain (the one which editorial accounts live in) fixes the issue.


5 thoughts on “Notes on an annoying misconfiguration

  1. I ran into the same scenario, but when I digged in this seemed to be a Sitecore ‘feature’. The intent of the preview button originally seems to have been to run as anonymous so that the current user’s security settings would not be applied, but also to mimic a standard anonymous user on the internet visiting a web page.

    More recent versions of Sitecore (7.2 and up, I believe) now have a Preview.AsAnonymous setting that allows you to configure whether to run as anonymous, or as the currently logged in user. I went so far as to build a module to give you an extra button so the author can choose:

    Interesting to know that sitecore\anonymous gets through the security. I’ll have to try this out! Thanks for digging down deep into it šŸ™‚

    • Cheers Jason. When I find some time I plan to raise this whole thing with Sitecore. I’m guessing they will agree that it is a feature – but I’m hopeful I might persuade them to update the error message to make it a bit more obvious what’s going on to others who hit a similar issue.

      Almost all my work is on legacy versions at present, so I’m not up to speed with how this might pan out on newer releases. But I’ll keep your module in mind for when I finally get all these projects upgraded to more recent versions…

      • Hey Jeremy, I actually built the module for older versions because I ran into the problem with a 6.6 client. The new setting starts in 7.2, so is another option aside from the module.

        I agree on the error message. If Sitecore intends it as a preview ‘feature’, then the preview should show the access denied page instead of redirecting to the home page.

  2. Pingback: Ok, how did I break Experience Editor this time? | Jeremy Davis

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

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