SPSecurity.RunWithElevatedPrivileges Method
Executes the specified method with Full Control rights even if the user does not otherwise have Full Control.
Assembly: Microsoft.SharePoint (in Microsoft.SharePoint.dll)
Available in Sandboxed Solutions: No
public static void RunWithElevatedPrivileges( SPSecurity..::..CodeToRunElevated secureCode )
Parameters
- secureCode
- Type: Microsoft.SharePoint.SPSecurity.CodeToRunElevated
A delegate method that is to run with elevated rights. This method runs under the Application Pool identity, which has site collection administrator privileges on all site collections hosted by that application pool.
The secureCode object can be created from any method that is parameterless and returns void. See SPSecurity.CodeToRunElevated.
You can also bypass using the SPSecurity.CodeToRunElevated constructor by defining an anonymous method inside the call to RunWithElevatedPrivileges.
Important
|
|---|
|
If secureCode includes any write operations, then the call to RunWithElevatedPrivileges should be preceded by a call of either SPUtility.ValidateFormDigest() or SPWeb.ValidateFormDigest(). |
The first example shows RunWithElevatedPrivileges used with the SPSecurity.CodeToRunElevated constructor. In this example, GetSitesAndGroups is a parameterless method that returns void and is defined somewhere that can be accessed by the Button1_Click method.
protected void Button1_Click(object sender, EventArgs e)
{
SPSecurity.CodeToRunElevated elevatedGetSitesAndGroups = new SPSecurity.CodeToRunElevated(GetSitesAndGroups);
SPSecurity.RunWithElevatedPrivileges(elevatedGetSitesAndGroups);
}
The next example shows the syntax that is required to define an anonymous method in the call to RunWithElevatedPrivileges.
SPSecurity.RunWithElevatedPrivileges(delegate()
{
// implementation details omitted
});
An SPSite object created outside the delegate can be referenced inside the delegate, however, the methods and property assessors of the object run with the privileges of the user context in which the objects were created, not with the elevated privileges. The same point applies to SPWeb objects and any other objects. You must create new objects inside the delegate if you need to execute the members of the objects with elevated privileges. If the new object must represent the same persisted entity as an object created outside the delegate, then you must reference identification information from the externally created object and use it to create the new object within the delegate. For example, if web is a reference to an SPWeb object created before the call to RunWithElevatedPrivileges, then the following code shows you would use the ID of its parent SPSite object to construct a new SPSite object.
SPSecurity.RunWithElevatedPrivileges(delegate()
{
using (SPSite site = new SPSite(web.Site.ID))
{
// implementation details omitted
}
});
Inside the delegate, members of the site object run with elevated privileges, but calls to members of web.Site would not. Note that the using keyword is used to ensure that the object is disposed in the delegate.
- 10/15/2011
- HaloX_69
- 10/15/2011
- HaloX_69
Behind the scenes, RunWithElevatedPrivileges impersonates the identity of the current thread. In effect, this means that the delegate will run under the context of the application pool account, in the case of the code being called in the W3P process, or in the context of the SPTimerv4 service, in the case of the code being called in a workflow, timer job or anything else that's kicked off using the timer. If the code is running in a console application or some other user-initiated app, the delegate will be kicked off using the context of the user who started the application. (Which would be the default behavior anyway).
When using workflows, bear in mind that the workflow may start running under W3P but continue executing under owstimer (SPTimerV4) depending on what it's actually doing. In this case a delegate executed using RunWithElevatedPrivileges would not neccesarily yeild the same result.
- 12/29/2010
- Charlie Holland
Important