A critical vulnerability was discovered in React Server Components (Next.js). Our systems remain protected but we advise to update packages to newest version. Learn More

Björn Olsson
Oct 11, 2011
  4906
(2 votes)

Virtual role validation behavior changed in EPiServer CMS6 R2

I recently upgraded a site to R2, and noticed that one of the custom virtual roles stopped working properly (The access rights in the edit page tree looked messed up). After some quick logging, I discovered that each virtual role only was validated once, when I expanded a node in the page tree. This would usually not be an issue for a virtual role, but in my case, the virtual role is based on each specific PageData object. This basically means, that the first child page in the node being loaded, would decide which access the user have for every following child page. This works as expected in R1 however (by default). I thought this was a bug in R2, so I created a support-ticket, at the same time, it also crossed my mind that this could be a performance enhancement. I got my answer a few days later, it’s a performance enhancement. But this can easily be overridden (if needed):

public class MyVirtualRole : EPiServer.Security.VirtualRoleProviderBase
{
    public override void Initialize(string name, System.Collections.Specialized.NameValueCollection config)
    {
        base.Initialize(name, config);

        this.EnableIsInRoleCache = false;
    }

    public override bool IsInVirtualRole(System.Security.Principal.IPrincipal principal, object context)
    {
        EPiServer.Security.PageAccessControlList acl = context as EPiServer.Security.PageAccessControlList;

        if (acl != null)
        {
            PageData page = EPiServer.DataFactory.Instance.GetPage(acl.PageLink);
            return page.PageName.Equals("Test", StringComparison.InvariantCultureIgnoreCase);
        }

        return false;
    }
}

This virtual role basically checks if the given page is named “Test”. But it won’t work as expected if EnableIsInRoleCache is set to true, which is default. This is, as I mentioned a performance enhancement, so don’t disable the cache unless needed, basically only if you are validating against the PageData object (or ACL) as this example, I can’t think of another scenario as I’m typing this.

And I’m out!

Oct 11, 2011

Comments

Please login to comment.
Latest blogs
Troubleshooting with Azure Application Insights Using KQL

Users at least get access to Azure Application Insights even within minimum access level if you are requesting access to DXP management portals at...

K Khan | Dec 21, 2025

Looking back at Optimizely in 2025

Explore Optimizely's architectural shift in 2025, which removed coordination cost through a unified execution loop. Learn how agentic Opal AI and...

Andy Blyth | Dec 17, 2025 |

Cleaning Up Content Graph Webhooks in PaaS CMS: Scheduled Job

The Problem Bit of a niche issue, but we are building a headless solution where the presentation layer is hosted on Netlify, when in a regular...

Minesh Shah (Netcel) | Dec 17, 2025

A day in the life of an Optimizely OMVP - OptiGraphExtensions v2.0: Enhanced Search Control with Language Support and Synonym Slots

Supercharge your Optimizely Graph search experience with powerful new features for multilingual sites and fine-grained search tuning. As search...

Graham Carr | Dec 16, 2025