Security context in SharePoint 2010

Security context in SharePoint 2010 

Introduction

In this article we will see various security concepts in SharePoint 2010. There are three main aspects which we have to understand

• SPContext
• RunWithElevatedPrivileges
• AllUnsafeUpdates

SPContext

SPContext class gets the context of the current HTTP request. The static Current property of the SPContext class provides properties that return context information about the current web application, site collection, site, list, list item, and so on.
The following code shows how we can use the properties of the SPContext class

1 2 3 4

SPList currentList = SPContext.Current.List; SPWeb currentWeb = SPContext.Current.Web; SPSite currentSite = SPContext.Current.Site; SPWebApplication currentWebApplication = SPContext.Current.Site.WebApplication;

Note: No need to dispose the objects returned from the SPContext class.

RunWithElevatedPrivileges

If we perform any operation in the server side code that the authenticated user is not authorized to perform, the user receives an Access Denied message.
For example,lets suppose we have written code in a webpart to navigate the subsites from subsites collection.
If any reader user tries to access this webpart page it gives access denied error.
SPSecurity class provides methods and properties for security management. By using the RunWithElevatedPrivileges method of this class, we can run a block of code in an application with elevated permission.

1 2 3 4

SPSecurity.RunWithElevatedPrivileges(delegate() {     // implement code here which will run for any user });

While using security elevation we need to ensure that we create a class instance from within the block of code that is to be executed inside the security elevated code block. Otherwise, the object will be created in the security context of current user but not the elevated permission user.
Note: When we execute the code with RunWithElevatedPrivileges, it will be impersonated with application pool account which is the highest level impersonation
Additional reference: RunWithElevatedPrivileges

AllUnsafeUpdates

Even though our code block is executing with elevated permissions, still to perform updates on the SharePoint object we need to perform one additional task. It is setting the AllowUnsafeUpdates property to true.
Setting this property to true allows our code to bypass security validation when making changes to SharePoint objects.
AllowUnsafeUpdates is to protect from cross-site scripting attacks. There are basically two scenarios where we would need to fiddle with AllUnsafeUpdates value:
• In case of an HTTP POST request, when using RunWithElevatedPrivileges for a user not having sufficient privileges to make changes to SharePoint objects
• In case of an HTTP GET request, when performing any changes to SharePoint objects, even for a user who has the required privileges to perform the operation
When we use SPContext to get the current web object and update values, it will not give error. But, after getting the web or list object from SPContext and if we are trying to get parent object of that, it will certainly give error when updating the values.