SXA duplicate main placeholder

Sitecore SXA & the main placeholder mystery

It sounds like a fairy tale and it almost was but a few hours were lost on this mystery so maybe writing this down can save someone some time in the future. 

What happened? We installed SXA on a XM environment with an already existing site (not using SXA, just a plain old MVC site). The idea was to use SXA for future sites that are being build on the same environment. But of course, we had to test if the current site was still working with this new framework installed.

The first tests seemed fine. The existing site was still working and we couldn't find any issues in the logs. But then we noticed that one placeholder was not working anymore in the Experience Editor. The site had a placeholder called "main" (as many sites probably do) which the editors will mainly utilize when creating new pages. The issue stayed under the radar when editing existing pages or even adding some new components as those are usually put in other placeholders.

So we faced an issue with the "main" placeholder. The person debugging this had knowledge of the current implementation but no real experience with SXA and was a bit lost. Although if you looked carefully at the placeholder definition item, Sitecore did give a pretty decent clue: 

Duplicate placeholder keys

Sitecore is telling us here that the key value should be unique. Which make sense of course. So we have to find out why this is suddenly happening and of course we should look into SXA. And yes, SXA als has by default a main placeholder for the MVC version: /sitecore/layout/Placeholder Settings/Foundation/Experience Accelerator/MVC/main.  As we have will only be using the headless version the easy fix was to change the placeholder key in this SXA item. 

Note that other placeholders keys are added as well, like header, footer, head...  so you might encounter this issue on those as well.

It appeared to be an easy fix for a trivial issue, but for those who are not acquainted with SXA this hopefully helps if you ever face this problem.

 

Sitecore Powershell Extensions - Elevated session state issues

 SPE - Elevated session state issues

Some time ago I faced a very weird issue on a local setup of Sitecore 10.2 which includes the wonderful Sitecore Powershell Extensions (SPE). I wanted to run a script and SPE requested elevated session state. As you probably know is you have been using SPE already this happens (quite often) and requires you to provide your password again.

The problem was that in my case my password didn't work. Although I was sure it was correct. I could use the same password to login in Sitecore. I had this issue only on my local environment, not on any other test or production environment.

So I started my investigation that actually surfaced a few things so it might be worth putting this in a blog post.

SPE identityserver config

First of all, make sure the necessary config file is present and not disabled: https://sitecore.stackexchange.com/a/28255/237. In "\App_Config\Include\Spe" rename Spe.IdentityServer.config.disabled to Spe.IdentityServer.config. And restart.

This didn't fix my issue though and then I bumped into some configuration that could disable the request for elevated session state. Normally I would never consider this, but the problem was only local so it might be worth doing - but my curious mind wanted to fix the issue instead of putting it aside. 

Disable elevation

If you do want to tamper with the elevation requirements, check the "App_Config\Include\Spe\Spe.config" file and find the following entries: 

<token name="Default" expiration="00:00:00" elevationAction="..."/>

<token name="Console" expiration="00:05:00" elevationAction="..."/>

<token name="ISE" expiration="00:05:00" elevationAction="..."/>

<token name="ItemSave" expiration="00:05:00" elevationAction="..."/>

To disable the requirement, put "Allow" in the elevationAction.

But as mentioned we continue to solve the issue properly. I can't remember where I actually got the idea to verify the SHA settings... but that was next on the list.

SHA - the hash algorithm

I hope you do know you can (and should/must) change the hashing algorithm on your site. This is explained in https://doc.sitecore.com/xp/en/developers/latest/platform-administration-and-architecture/change-the-hash-algorithm-for-password-encryption.html.  

To do so, you need to update two files. The web.config file in the website needs an updated hashAlgorithmType setting (eg to SHA512). And if you use Sitecore Identity, you must also change the algorithm on the Sitecore Identity server. 

And apparently that was my issue. On the local environment I had no automated publish towards the Identity Server and so the hash algorithm was not changed there. I still think it's pretty weird that I could login to Sitecore with those settings but well.. I did. It's only when using SPE that this turned into a problem. Settings the hash to the same value as in the web.config fixed it all.

Conclusion

If you run into issues with elevated session state login:

• check the SPE config folder if you have all necessary configs enabled
• check whether the hash algorithm on the site and on the Identity Server are the same
• check if your user is not locked (after a few failed attempts that might happen ☺) 

And if needed, you can also disable the elevation although I would not recommend doing so.