Sitecore JSS extranet security

 Extranet with Sitecore JSS and NextJS

Creating an extranet in a headless setup isn't always that straight forward. It is not up to your content management system (in this case Sitecore) anymore to deliver pages and as such also not to check who is actually demanding which content.  The Sitecore security settings as we used in the XP days are not sufficient here.

In this case we also had a few particular requirements and architectural choices:

• users are not stored through Sitecore, but in a custom database
• roles are maintained in Sitecore (as content items)
• pages can be visible for people from one or more roles, or even for people without a role (not yet registered guests)
• components can have security settings that define which role(s) can view the component
• API calls are also using the roles as security guidelines to determine who can get which data

Let's focus on the parts that get us in touch with Sitecore. So we need a solution that can set security on pages and components for roles defined and known in Sitecore. 

Pages

We created a base template with 2 fields:

• a multiselect field to select one or multiple roles
• a checkbox field to set the page open for everyone - including guest without a role

As we do not want to close pages for everyone (would be silly - one could unpublish the page if you want that) we also count no selected roles as all roles. 

This base template is added to all page templates. As this data is part of the page data, it is included when a page is requested by the NextJs app and can be used by that app to handle the security appropriately - send a 403 page if the page is not available for the current user.

I'm afraid I cannot share code in this article so you'll have to do with the ideas. But if you are familiar with NextJs development (which I am not btw) I would assume that this is not rocket science.

A small tip however: do not forget to check editing mode, as you do not want the security rules to be adapted when editing. 

Components

For the components, we used a similar setup. We created another base template that can be included in a component - it will not be included in all components, just in those where we want the security functionality.  This creates also a similar setup in the front app as that will receive the security data and display the components based on what it knows about the current user. 

Again, don't forget to skip the security check when editing. Although it can look weird when you have multiple components targeted at different roles, you still want to be able to edit everything.

Options

I assume there would be other options to tackle our request. It feels a lot like personalization so we also thought in that direction, but in the end our solution seemed like a simple one that would do as expected. And it is - the implementation was fairly easy and fast and the editors find their way when editing the pages and components. 

As I could only share the conceptual ideas here I hope you found it useful. And if you have any other thoughts or ideas on how to handle such requirements, I would be happy to discuss those. Always eager to learn ;) 

Sitecore JSS Dictionary performance

 Sitecore JSS Dictionary performance tuning

We implemented a headless site with NextJS and a Sitecore 10.2 with SXA - headless SXA. The code generated by Sitecore when creating the project included all we needed to work with the SXA dictionary in a dictionary-service-factory.ts. In combination with the i18n setup this allows us to easily create and use translatable labels in our application. It works fine. 

But.. would someone please take a look at the logs...

Always watch the search logs

After a while we checked the logs to see if anything fishy was found - always a good practice, even during development cycles and when you think everything is smooth. And we noticed a lot of identical queries:

INFO  Solr Query - ?q=(((path6d119245ea284770a401ee68458abfc5) AND _language"en")) AND _templates6d1cd89719364a3aa511289a94c2a7b1)) AND _path0de95ae441ab4d019eb067441b7c2450)) AND _val:_boost&start=30&rows=10&fl=*,score&fq=_indexname:(sitecore_web_index)&wt=xml&sort=_smallcreateddate_tdt desc,_group asc

It didn't ring a bell immediately but when we executed this query in the solr admin it was very clear that this was related to the dictionary. Apparently our next app was fetching the dictionary data quite often. And in small pieces. The combination of both settings leads to a lot of queries. Even though they are probably very fast, I still thought it could be improved as the labels in our dictionary will not change frequently. 

Tweaking the DictionaryService

In the dictionary-service-factory.ts file, check for the GraphQLDictionaryService instance creation (we are using the GraphQL version):

new GraphQLDictionaryService({
      endpoint: config.graphQLEndpoint,
      apiKey: config.sitecoreApiKey,
      siteName: config.jssAppName,
      ...

Looking at the options available for this service, we found we could set a pageSize and a cacheTimeout. There is also a parameter cacheEnabled but that is true by default.  Note that the cacheTimeout has a default of 60 (seconds) and the pageSize has a default of 10 (as seen in the rows parameter in the solr query). 

For our implementation and with the number of dictionary items we have that is inefficient. We need a larger pageSize and a larger timeout. 

  new GraphQLDictionaryService({
          endpoint: config.graphQLEndpoint,
          apiKey: config.sitecoreApiKey,
          siteName: config.jssAppName,
          rootItemId: '....',
          pageSize: 150,
          cacheEnabled: true,
          cacheTimeout: Number(process.env.DICTIONARY_CACHE_TIMEOUT),

With this adjustments our dictionary was still working fine - but we had a lot less queries to solr. Note that we decided to get the timeout from an environment variable so we could tweak that between environments. You could do the same for the page if you want.

Enjoy the tips and happy dictionaring 🙂 

How to kill your Sitecore editor with one slash

 Is your page opening really slow in the Sitecore Content Editor?

I recently had an issue where one page (the homepage) of a site opened really slow in the Sitecore Content Editor. All other pages went very smooth, so it was clearly something particular to that page. And when I mean slow, I mean you click on the item and it takes one coffee for the editor to react. On the published site, there was no issue.

At first this was just annoying, but after a while you curious and annoyed and you want this fixed.

Debugging

The editor is pure Sitecore coding so how to start... one way is to enable the timing level for all events.

You will find this setting in the Sitecore.config file and if this is just for temporary debugging on a local instance you can alter it there. 

<!-- EVENT MAPS
      events.timingLevel =
        none   - No timing information is logged for any of the events (no matter what their local settings are)
        low    - Start/end timing is logged for events with handlers. Local settings override.
        medium - Start/end timing is logged for all events. Local settings override.
        high   - Start/end timing is logged for all events. Also, start/end for each handler is logged. Local settings override.
        custom - Only local settings apply. Events without settings are not logged.
    -->
  <events timingLevel="custom">

So we will change the timingLevel for all events to "high" instead of custom and restart the site.

Now let's keep an eye on the logs while we go back to the editor and open our homepage item. And bingo.. we get a lot of information in the logs but what was really interesting were the lines that said "Long running operation".

Long running operation

20204 11:29:46 DEBUG Long running operation: renderContentEditor pipeline[id={98E57B60-071A-44D1-A763-B6C1BCE0C630}]
20204 11:29:48 DEBUG Long running operation: getLookupSourceItems pipeline[item=/sitecore/templates/Feature/.../CtaRenderingParameters/__Standard Values, source=query:/$site/Data/.../*]
20204 11:29:50 DEBUG Long running operation: getLookupSourceItems pipeline[item=/sitecore/templates/Feature/.../CtaRenderingParameters/__Standard Values, source=query:/$site/Data/.../*]
20204 .....
20204 11:30:19 DEBUG Long running operation: getLookupSourceItems pipeline[item=/sitecore/templates/Feature/.../CtaRenderingParameters/__Standard Values, source=query:/$site/Data/.../*]
20204 11:30:19 DEBUG Long running operation: Running Validation Rules

Apparently we have a long running operation getLookupSourceItems and we are not doing this once, but a dozen times on the home page.  This is our cause - and ok, I exaggerated when I said a coffee but even a minute feels long to open an item.

So, we now now that the CtaRenderingParameters are doing something very slow and it is caused by the source for a field.

In that template I found (even two) droplist fields that use the same source: 

query:/$site/Data/Link Types/*

I am not writing Sitecore queries every day so I admit it took me a few minutes to figure out what was wrong with this thing. It looks like a normal query that fetches all items in a certain path. And it's just a small detail, but a significant one: the first slash should not be there 

query:$site/Data/Link Types/*

This works much smoother and the issue was fixed.

$site

We are using a resolveToken in the source. In the Sitecore docs you will find the list of available tokens and we are using $site here to get the path to the current site. 

But that path will already start with a slash. So although you (probably) want your query to start with a slash, you do not want it to start with two. As described in the query axes, one slash will give you the children (and will form one path) but two will give all descendants. And that is in most cases a very costly operation.

Conclusion

Be careful when putting sources - especially when using tokens. You might not notice anything bad or slow when just one component is added, but it can add up to a really slow item. Use the events timing level to get debugging information.

Sitecore SXA - XP navigation bar site resolving

Sitecore Experience Editor - navigation bar site resolving issue

Situation

We inherited a Sitecore 10.2 setup with a number of sites created with old school MVC. Nothing really fancy, just a bunch of sites just as many other solutions probably. The setup is a little weird (just as many "inherited" solutions, right...) and the customer is not used to working in the XP editor. 

When we were asked to add one more site, we decided to go for a headless approach and installed JSS and SXA on the environment. This is all working fine - all sites are running fine and I dare to say the new site is much more towards all best practices. And also introducing the XP editor - especially to add new components to a page. With the SXA extensions that is working like a charm.

Although we noticed one little issue. The navigation bar in the XP editor didn't work as expected. 

We can open a page in the XP editor and it works - the url looks like

https://dev/?sc_mode=edit&sc_itemid=...&sc_lang=en&sc_version=1&sc_site=portal.

But when we then use the navigation bar to go to another page we get an error because the sc_site parameter in the url is wrong:

https://dev/site1/?sc_mode=edit&sc_itemid=...&sc_lang=en&sc_site=site1&sc_ee_fb=false.

When we manually change the sc_site parameter back to "portal" it works. It seems that it takes the first site in the site definition list.

Site configuration

First thing to check is the site configuration. That seemed to be fine - we also checked the SXA Site Manager and that as well was all ok. 

Note here that the mvc sites are in the config (files), the SXA site is configured in Sitecore (items). This makes is tricky to order them.

There is a SiteResolving config section from SXA where you can add sites that should be resolved after the SXA sites. Just to be sure we added all sites to that list in the config:

<siteResolving patch:source="Sitecore.XA.SitesToResolveAfterSxa.config">
  <site name="exm" resolve="after" />
  <site name="website" resolve="after" />
  ....
</siteResolving>

When all sites are added you can see in the SXA Site Manager that the SXA site moved up and that is now our first site.

Unfortunately, that didn't solve our issue. The site resolving in the navigation bar is still wrong. 

The solution

We contacted Sitecore Support. I thought about trying to find the responsible code to see if I could fix it myself - didn't do that as it would take too much time for something that is not convenient but also not blocking. 

And finally none of those options solved it, but well - let's call it luck. I can't remember why I decided to add a targetHostName in the site definition of the new SXA site. But I did - and actually that fixed our issue. The site resolving is working fine now.

We still don't know exactly why and don't want to spend time searching for a root cause but it is solved and might solve a site resolving issue for you as well. If anyone would know the root cause, please do share though.

Sitecore EXM - issue with long name emails

 Sitecore EXM - emails with long names

Our customer is using Sitecore Email Experience Manager to send campaigns (e-mails) to their contacts.  We got notified that they had an issue with a specific campaign that was not sending. 

First of all we noticed that the email was completely blocked in the EXM management tool. We could not de-activate it to try to change anything which was pretty weird. Luckily the logs showed us some meaningful information.

ERROR Exception: Sitecore.Exceptions.InvalidItemNameException

Message: An item name lenght should be less or equal to 100.

Source: Sitecore.Kernel

   ....

   at Sitecore.EmailCampaign.Cm.Pipelines.DispatchNewsletter.DeployAnalytics.AddCampaignItem(MessageItem message)

 

An item name lenght should be less or equal to 100

Yes, item length - that is the issue. (including the typo in the exception message 😊)

But what item name? Yes, the name of the email was long, but not that long. EXM does check the length of the name - just try to type more than 100 characters in the name field of a new regular mail and it will turn red. 

Let's have another look at the trace in the error message - it seems to be from "AddCampaign" and that rings a bell. When a regular email is created, Sitecore also creates a campaign item in /sitecore/system/Marketing Control Panel/Campaigns. When we check the names of the items there it seems to be the name of the mail campaign with the item id (guid). This means that this item is 36 characters longer than the mail name - leaving us with only 64 characters for the mail name. 

Which is fine - if you know it. And yes, that should be checked in EXM. You can consider this a bug -it is- but I'm not going to patch a solution for it. 

Fix ?

We could try and patch it ourselves, but it's actually not worth the effort. We could also increase the MaxItemNameLength but again - don't seem worth it. Note that we are talking about the name of the mail campaign, not the subject or anything the end customer would see.

So we decided to just fix the impacted mail and inform the customer to use shorter names in future (until we move the solution to Sitecore Send 😛)

Fixing locked mail items

Fixing the item seemed to be not that easy actually as it was really locked. I could not deactivate it to edit it. An old trick to the rescue, described on Sitecore Stack Exchange (of course... ) in another situation but still very useful. 

Go to the content editor and locate the mail item. Unprotect it and make the changes you want - in this case shorten the title.  Protect the item again - use the "Open EXM" button to go to the item where you now can de-active and activate again.  And that should fix your mail.

Conclusion

One more reason to start moving the mail part of the solution to Send...

Sitecore SXA Responsive Image - null reference

 SXA Responsive Image null reference issue

We recently faced an issue on Sitecore SXA with the Responsive Image component. Our customer informed us that if an image was not published pages containing that image would be broken. And not just missing the image - but actually broken. 

The site is running on Sitecore 10.2 using SXA - and the site is patched with the latest hotfix packages so actually running on 10.2.1 (and even 10.2.2 now). On the broken pages we had renderings that use the ootb Responsive Image rendering variant. So it was clear that the issue was with that component.

In the release notes for version 10.3 we found the matching bug: 

If a Responsive Image variant field points to a broken link, a NullReferenceException error occurs.

Upgrading is 10.3 is not an option. So let's try to fix this ourselves. I found the issue in the class Sitecore.XA.Feature.Stylelabs.Pipelines.RenderVariantField.RenderFallbackResponsiveMImage which came with the 10.2.1 update. The RenderField method in that class uses a function called StylelabsDataExtractor.GetSrcAttributeValue. That is weird as this one is deprecated in 10.2 and it mentions to use the new function GetAttributeValue. When I tried the same code with that function the error was gone. 

So let's recap that and show the code you need.

using System.Web.UI;
using Sitecore.Data.Fields;
using Sitecore.Data.Items;
using Sitecore.Web.UI.WebControls;
using Sitecore.XA.Feature.Stylelabs.Services;
using Sitecore.XA.Foundation.Variants.Abstractions.Pipelines.RenderVariantField;

namespace Foundation.Infrastructure
{
    public class RenderFallbackResponsiveMImage : Sitecore.XA.Feature.Stylelabs.Pipelines.RenderVariantField.RenderFallbackResponsiveMImage
    {
        public RenderFallbackResponsiveMImage(IStylelabsDataExtractor stylelabsDataExtractor) : base(stylelabsDataExtractor)
        {
        }

        public override void RenderField(RenderVariantFieldArgs args)
        {
            var variantField = args.VariantField;
            if (args.Item.Paths.IsMediaItem || string.IsNullOrWhiteSpace(variantField?.FieldName))
            {
                base.RenderField(args);
            }
            else if (PageMode.IsExperienceEditorEditing)
            {
                args.ResultControl = (Control)new FieldRenderer()
                {
                    Item = args.Item,
                    FieldName = variantField.FieldName,
                    DisableWebEditing = !args.IsControlEditable
                };
                args.Result = this.RenderControl(args.ResultControl);
            }
            else
            {
                var field1 = args.Item.Fields[variantField.FieldName];
                if (field1 == null)
                {
                    return;
                }

                if ((FieldTypeManager.GetField(field1) is ImageField field2 ? field2.MediaItem : (Item)null) == null)
                {
                    field2 = (ImageField)field1;
                    string srcAttributeValue = this.StylelabsDataExtractor.GetAttributeValue("src", field2);
                    Control fieldRenderer = this.CreateFieldRenderer(args);
                    this.RenderControl(args, fieldRenderer, srcAttributeValue);
                }
                else
                {
                    base.RenderField(args);
                }
            }
        }
    }
}

Note the usage of this.StylelabsDataExtractor.GetAttributeValue("src", field2);

To get this code working instead of the original one we can patch the configs and insert this into the dependency injection:

<sitecore>
  <pipelines>
    <renderVariantField>
      <processor patch:instead="*[@type='Sitecore.XA.Feature.Stylelabs.Pipelines.RenderVariantField.RenderFallbackResponsiveMImage, Sitecore.XA.Feature.Stylelabs']"
				type="Foundation.Infrastructure.RenderFallbackResponsiveMImage, Foundation.Infrastructure" resolve="true" />
    </renderVariantField>
  </pipelines>
</sitecore>

That's it. Don't forget if you ever upgrade to remove this code of course. 

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.