Microsoft Windows SharePoint Services uses impersonation so that code running within a Web Part or behind a custom application page executes with the identity and permissions of the current user. In the vast majority of cases, this behavior is exactly what you want because it prevents standard users from being able to execute commands or see information that is intended only for privileged users such as a site administrator. However, occasionally your code must call restricted methods within the Windows SharePoint Services object model even though the request is initiated by a nonprivileged user. In such cases you must be able to elevate the privilege of your code as it executes on the Web server.

Assume that you have a Web Part in which you want to display information obtained through the Windows SharePoint Services object model, such as the name of the current site collection owner, usage statistics, or auditing information. These are examples of calls into the object model that require site-administration privileges. Your Web Part experiences an access-denied error if it attempts to obtain this information when the current user is not a site administrator. However, you can still successfully make these calls into the object model by calling the RunWithElevatedPrivileges method provided by the SPSecurity class.

SPSite siteColl = SPContext.Current.Site;
SPWeb site = SPContext.Current.Web;
SPSecurity.RunWithElevatedPrivileges(delegate() {
  using (SPSite ElevatedsiteColl = new SPSite(siteColl.ID)) {
    using (SPWeb ElevatedSite = ElevatedsiteColl.OpenWeb(site.ID)) {
      string SiteCollectionOwner = ElevatedsiteColl.Owner.Name;
      string Visits = ElevatedsiteColl.Usage.Visits.ToString();
      string RootAuditEntries = 
          ElevatedSite.RootFolder.Audit.GetEntries().Count.ToString();
    }
  }
});

The RunWithElevatedPrivileges method accepts a delegate parameter that adds a reference to a method that contains the code that is to be executed with elevated privileges. The Microsoft Visual C# syntax you see in the previous example contains the delegate keyword that demonstrates using anonymous methods to write delegate code inline within another method. The Microsoft Visual Basic example differs from the C# one because it does not support writing a delegate method inline by using anonymous method syntax. Therefore, you must write the code that is to run with an elevated security context in its own separate methods as a Sub procedure that accepts no parameters.

Sub MyElevatedMethod()
  Dim siteColl As SPSite = SPContext.Current.Site
  Dim site As SPWeb = SPContext.Current.Web
  Using ElevatedsiteColl As SPSite = New SPSite(siteColl.ID)
    Using ElevatedSite As SPWeb = ElevatedsiteColl.OpenWeb(site.ID)
     Dim SiteCollectionOwner As String = ElevatedsiteColl.Owner.Name
     Dim Visits As String = ElevatedsiteColl.Usage.Visits.ToString()
    Dim RootAuditEntries As String = _
        ElevatedSite.RootFolder.Audit.GetEntries().Count.ToString()
    End Using
  End Using
End Sub

After you write a method such as MyElevatedMethod, you can execute it with elevated privileges by invoking the RunWithElevatedPrivileges method and passing a delegate reference created with the Visual Basic AddressOf operator.

SPSecurity.RunWithElevatedPrivileges(AddressOf MyElevatedMethod)

After you elevate the privileges of your code by calling RunWithElevatedPrivileges within the context of a Windows SharePoint Services request, you must then create an instance of the SPSite class and the SPWeb class. You cannot use the objects available through the Microsoft.SharePoint.SPContext.Current property. That is because those objects were created in the security context of the current user. The code shown in this document demonstrates how to create these new objects after having elevated privileges. Also note that objects of type SPSite and SPWeb are disposable objects that are best used within Using statements to ensure that the Dispose method is called in a timely fashion.

Finally, realize this technique is very powerful in that the code executes under the identity of the SHAREPOINT\System account. This account has full administrative privileges over every site collection within the current farm. With the power of this technique also comes the responsibility to ensure that you do not write code that allows users to access information and content and run commands to which they should not have access.

Watch the Video

Video Length: 00:04:56

File Size: 12.2 MB WMV

• Item-Level Auditing with SharePoint Server 2007

• SharePoint Server 2007 Developer Portal

• Office Developer Center