Sitefinity ElevatedModeRegion: When and How to Use It

Your code works when you're logged in as an admin and throws an authorization exception the moment an anonymous visitor runs it. That's Sitefinity's permission system doing its job: managers check the current user before they read or write. ElevatedModeRegion tells one manager to skip those checks for a few lines.

using Telerik.Sitefinity.Data;

var manager = UserManager.GetManager();

using (new ElevatedModeRegion(manager))
{
    // permission checks are off for this manager's provider inside the block
    var user = manager.GetUser(email);
    // ...change the user...
    manager.SaveChanges();
}

It lives in Telerik.Sitefinity.Data

The class is barely documented, so the first problem is usually getting it to resolve at all. You need using Telerik.Sitefinity.Data;. Feather's own source refers to it as Data.ElevatedModeRegion in one file, which settles the namespace.

Pass it the manager you write through

Every use in Sitefinity's public GitHub repositories hands it a manager. The Enhanced Forms installer wraps ConfigManager.SaveSection, the Feather content block wraps ContentManager.CreateContent, and the identity widgets wrap UserManager and UserProfileManager. The samples do the same with PageManager and RoleManager.

People search for new ElevatedModeRegion() and new ElevatedModeRegion(null). We couldn't find a single official call shaped like either, so pass the manager.

One region per manager

The region suppresses security checks on that manager's provider and nothing else. Feather's registration widget (RegistrationModel) opens one region around its UserManager work and a separate one around the UserProfileManager it saves the profile through. If your code writes through two managers, wrap both:

var userManager = UserManager.GetManager();
var profileManager = UserProfileManager.GetManager();

using (new ElevatedModeRegion(userManager))
using (new ElevatedModeRegion(profileManager))
{
    // ...
    userManager.SaveChanges();
    profileManager.SaveChanges();
}

Keep SaveChanges() inside the block, the way every official example does. The checks come back on when the region is disposed.

Stop setting SuppressSecurityChecks by hand

The older way is manager.Provider.SuppressSecurityChecks = true;. Telerik's advice on the forums was to wrap that in a try/finally and set it back to false afterwards. Forget the reset, or throw before you reach it, and that provider stays wide open for whatever it does next. A using block gives you that finally without having to remember it.

Some services don't go through a manager's checks at all. They look at who the current identity is. Search is the one that caught us. With enableFilterByViewPermissions set in SearchConfig, the Lucene service trims results to what the current identity may view. We hit this building the settings search in our Sitefinity MCP server: an MCP request carries an API key, not a Sitefinity user, so the search returned zero hits and no error. The same query works in the admin UI only because a backend user is logged in there.

ElevatedModeRegion can't help with that. SystemManager.RunWithElevatedPrivilege runs a delegate as an unrestricted user:

SystemManager.RunWithElevatedPrivilege(args =>
{
    // runs as an unrestricted user
});

The full signature also takes an optional object[] parameters and a string urlRequest. Telerik describes it as simulating "the HttpContext as it was called with a system user in admin role", which is also why it fits scheduled tasks and background threads where there's no request user at all. On the forums it's the fix people report for manager errors in multi-threaded code.

For one manager refusing you inside a normal request, stay with ElevatedModeRegion, which changes far less.

The other regions stack the same way

ElevatedModeRegion has siblings that switch other parts of the context. AllProvidersAccessRegion lets a manager reach every provider, SiteRegion.FromSiteId(siteId) runs as a specific site, and CultureRegion runs in a culture. Background code that touches multisite or multilingual content needs the site and culture regions, or it resolves against the wrong site. Sitefinity's own resolver code stacks all four:

using (new AllProvidersAccessRegion())
using (new ElevatedModeRegion(manager))
using (SiteRegion.FromSiteId(siteId))
using (new CultureRegion(culture))
{
    // ...
}

There's also UnrestrictedModeRegion, which drops security restrictions entirely. It's the blunt option, so keep it for code where you'd otherwise reach for RunWithElevatedPrivilege.

Keep the region around the write

Everything inside the region runs as though the current user is allowed to do it. Validate the input and decide whether this visitor should be able to do this before you open the block, then wrap only the write. The registration widget works this way: an anonymous visitor creating an account needs elevation, and that's also where you most need to check what they sent.

If you find yourself wrapping a whole controller action in one, the permission it's bypassing is probably the one you should be configuring instead.

Sitefinity ElevatedModeRegion: skipping permission checks the right way