February 19th, 2015
  • Programmically change items
  • EPiServer
  • NullReferenceException
  • Html.RenderAction

Programmatically changing EPiServer items - The nice way

When you use MVC and you use Html.RenderAction within your view, you cannot use the 'Alloy' logic to programmatically add, update or remove pages and/or blocks in EPiServer within your action or constructor. If you do, you can expect an 'Object reference not set to an instance of an object' upon your 'Html.RenderAction' line when you try to edit the page in the EPiServer backend.

With the 'Alloy' logic I mean:

PrincipalInfo.CurrentPrincipal = new GenericPrincipal(new GenericIdentity("Task"), new[] { "Administrators" });
/* Update, modify or delete EPiServer items */
PrincipalInfo.CurrentPrincipal = null

This NullReferenceException occurs because you dump your EPiServer user for the rest of your request and this causes EPiServer to not know which language, etc. to use to render the action.

But even without the NullReferenceException, this is not the right way to remove the temporary created administrator principal.

You could better create a SecurityDisabler:

using EPiServer.Security;
using System;
using System.Security.Principal;

namespace Your.Namespace
{
    public class SecurityDisabler : IDisposable
    {
        private readonly IPrincipal _principal;

        public SecurityDisabler()
        {
            _principal = PrincipalInfo.CurrentPrincipal;
            PrincipalInfo.CurrentPrincipal = new GenericPrincipal(
            new GenericIdentity("Task"),
            new[] { "Administrators" });
        }

        public void Dispose()
        {
            PrincipalInfo.CurrentPrincipal = _principal;
        }
    }
}

Using it you can change EPiServer pages and/or blocks programmatically without ever having any side effects:

using (new SecurityDisabler())
{
    /* Update, modify or delete EPiServer items */
}
< Previous post Overview posts Next post >
Hi Johan, I'm not really sure why we've decided to not used this method. We’ve investigated this a long time ago, so I don’t know exactly why we decided to use the SecurityDisabler. I think there was an issue with the AccessLevel.NoAccess flag in specific situations, but again: I’m not sure anymore.
Laurens Huizer, February 24th, 2015
There is a simpler way to bypass the security check when saving content: var repository = ServiceLocator.Current.GetInstance<IContentRepository>(); repository.Save(page, SaveAction.Publish, AccessLevel.NoAccess); Notice the AccessLevel.NoAccess flag.
Johan Petersson, February 24th, 2015

Leave a comment

= Thanks for your comment =