Sitecore Item access based on external data

Sometimes you might want to disable read access on items in your website based on something that doesn’t reside in Sitecore, like for example external data that comes from your own database. We have run into a situation where we had purposely chosen not to use the Sitecore role provider for several reasons and found a way to still apply the necessary security checks to make sure some items were not visible for all users on our portal. Our real Sitecore user was extended with some roles in our own database and we wrote an ItemProvider that would deal with this custom scenario. The methods that override the base implementation have been decompiled and slightly adjusted to serve our needs:

And the following configuration patch:

You can see that we wrote an extension on the ‘Item’ to find out if a user has access to this item (with custom logic). You can implement your own logic that will decide if the item should be returned when using the Sitecore API to fetch items. This provider will make sure that the functionality hooks in to the regular calls you make to retrieve items.

Improving performance with custom cache keys in Sitecore

Out of the box Sitecore offers you a considerable amount of usable cache keys to improve the speed of pages served from your platform. The standard provided cache keys are quite powerful in optimising the user experience. The image below shows how we can setup a rendering to be cached based on the page it’s served at:

We selected the checkbox ‘Cacheable’ so the rendering knows it can be served from cache. With no other options selected this rendering will be rendered once from the Controller logic and View and from that point on will be served from the cache as it was rendered the first time. This is cool for renderings that only have one appearance like for example a logo on a single website platform. When you want to start varying the renderings based on other parameters like ‘data’ (the page the data is displayed at), you will notice that Sitecore generates different cache keys to serve this data.

For example:

  • We have a ‘ImageSlider’ (rendering) with the options ‘cacheable’ and ‘vary by data’ activated.
  • We place this rendering on 2 pages in Sitecore.
  • We select the same datasource for both renderings, called ‘Slider1’ with the appropriate data we want to display

Now on those two pages the rendering is placed on, Sitecore will generate a cache key looking something like this:

Sitecore now renders this ‘ImageSlider’ once and for the other page it generates the same cachekey, resulting in serving the same html from cache.

For one of our customers we run a multi-site setup with some customisations regarding datasources. You can read more about our customisation here and specifically check ‘Queryable Datasource’. Because we made a modification to Sitecore, in our case the ‘vary by data’ option was not working as Sitecore doesn’t recognize our datasource as a correct datasource. This resulted in renderings that all got cached on the same key, even though we gave them our own custom datasource (which was valid for us).


With the following datasource:

Which enables us to setup standard templates for websites on our multi-site platform with queryable datasources, which can be very powerful.
Now with this customization we also needed our own specific variable datasource option to enable caching to the footerblocks:

Here you can see I created our own cache key called ‘VaryByDataSource’ which will retrieve the correct datasource and add it to the cache key and in turn enables us to cache this rendering. This is just an example of a custom cache key, and we also created some other cache keys like ‘VaryByWebsite’, ‘VaryByProduct’ and ‘VaryByCategory’. The vary by website cache key is very powerful when you want to make sure a rendering is always uniquely rendered on a website. Maybe your own platform requires some of these unique custom caching keys? It’s very easy to create your own actually!

Step 1:

Expand the inherited ‘Cache’ template with ID ‘{E8D2DD19-1347-4562-AE3F-310DC0B21A6C}’. You can create some new checkbox fields there, that will make sure you can select the option on all of your Controller Renderings.

Step 2:

Create a new class called ‘GenerateCacheKey’ somewhere in your solution. Make sure it’s built and available in the assembly folder of your application. Below you find an implementation (dev) that we created. The VaryByWebsite could be useful in your own scanario.

Step 3:

Override the ‘GenerateCacheKey’ class that Sitecore MVC is using to generate a cache key for a rendering:

You will notice, that for custom logic, it will be a very good idea to really think ahead about which factors have to modify the cache keys (for a rendering) to make sure you can benefit from caching without sacrificing functionality.