Using RunWithElevatedPrivileges in SharePoint

As users browse and use SharePoint, the content is retrieved and written under the context of that user, therefore, they can only read and write to what they have permissions to. When developing custom components in SharePoint, whether it be a web part, application page, event handler, etc.…, developers often need to read and write to lists and libraries where the logged in user may not have permissions. For example, we may have a custom web part that pulls specific data from a secure list and displays it in a dashboard. Or we need to pull configuration data from a list where we don’t want the user to have direct access.

In this case, developers can take advantage of RunWithElevatedPrivileges in SharePoint. Any code executed with elevated privileges runs as the System Account and therefore has access to everything. At first, the code needed to run with elevated privileges seems like a piece of cake. However, there are some details that developers should be aware of. I’ve created some simple web parts to display the differences in the way elevated privileges is used.

To start, here is an example of code running without elevated privileges:

///

/// Example 1 shows the current site and the current user.

///

private

void

ExecuteExample1()

{

this

.SiteLabel.Text = SPContext.Current.Web.Title;

this

.UserLabel.Text = SPContext.Current.Web.CurrentUser.Name;

}

 image

image

Next, we’ll look at a common mistake made when running with elevated privileges:

///

/// Example 2 shows the incorrect usage of elevated privileges.

///

private

void

ExecuteExample2() { SPSecurity.RunWithElevatedPrivileges(

delegate

{

this

.SiteLabel.Text = SPContext.Current.Web.Title;

this

.UserLabel.Text = SPContext.Current.Web.CurrentUser.Name; }); }

At first, you would assume that any code running within the SPSecurity.RunWithElevatedPrivileges would run as the System Account. However, here are the results.

 image

image

Notice that the Current User is still myself, and not the System Account. This is because any objects created within SPSecurity.RunWithElevatedPrivileges code block will run under the System Account, but SPContext.Current.Web is actually created outside of this code block. This is the key to using elevated privileges successfully. It is tricky to master (at least for me) especially when dealing with more complicated code.

Next is an example of the correct usage of elevated privileges:

///

/// Example 3 shows correct usage of elevated privileges.

///

private

void

ExecuteExample3() { SPSecurity.RunWithElevatedPrivileges(

delegate

{

using

(SPSite site =

new

SPSite(SPContext.Current.Site.ID)) {

using

(SPWeb web = site.AllWebs[SPContext.Current.Web.ID]) {

this

.SiteLabel.Text = web.Title;

this

.UserLabel.Text = web.CurrentUser.Name; } } }); }

 image

image

Notice that the SPWeb object we are using is created within the RunWithElevatedPrivileges code block. Now our current user is showing as the System Account as it should.

Now any code executed using this instance of the SPWeb object will run with the permissions of the System Account. We no longer need to worry about the permissions of the current user.

The usage of elevated privileges still has some consequences that may need to be dealt with. For example, if you write data to a list or library using elevated privileges, the item will be added with the System Account as the user, rather than the actual current user as you may expect. In this case you’ll need to update the SPListItem that was created with the actual user account.

Eric GregorichComment