Learning: How to Enhance permissions for Sharepoint Programming

This article comes from the Network (http://www.sharepointblogs.com/tanujashares/archive/2007/08/07/impersonation-in-sharepoint-2007.aspx ):

During SharePoint programming, you sometimes need to modify an item in the list, but the current login user does not have the permission to modify the list. Generally, you can do this in two ways during programming, the following describes the two methods:

Impersonation in SharePoint 2007

 

SharePoint security model makes it easy to programmatically execute code within the current user context.

Just write and deploy Web Part/event handler code and it runs in the security context of the logged in user. there are even built-in functions that take advantage of the user's security context-such as getsubwebsforcurrentuser ()-without requiring any extra coding on our part which is simple yet valid tive security mechanisms.

But there are situations when the code needs to be executed with permissions greater than that of the current user (like instantiating a site collection or enumerating list permissions or reading a lookup/configuration list on which user may not have access rights ).

In such situations, the code needs to be executed with elevated permission level or under the context of user with higher permissions I. e. impersonation.

So here are the two approaches for U ----

Method 1 executing code as another named user

Process

When we create a Sharepoint site programmatically usingMicrosoft. SharePointNamespace, we can supply a User Token which enables you to create objects in the context of a specific user. You can impersonate a user by supplying the User Token for that user, obtained fromMicrosoft. Sharepoint. spuserObject. The User Token,Spusertoken, Is a binary object that contains the identification and domain group membership of a user.

This allows you to use the Microsoft. Sharepoint. spsite constructor to instantiate a site collection object that runs as if that user was making changes.

Spsite site = new spsite ("sitecollection_url ");

Spweb web = site. openweb ();

Spuser user = web. allusers ["user_name"]; // user_name generally supports SharePoint \ System

Spusertoken token = user. usertoken;

Spsite impersonatedsitecollection = new spsite ("sitecollection_url", token );

 

(Before modification, use web. allowunsafeupdates = true; after modification, assign the value to false.

Note that the user is already a Sharepoint \ SYSTEM user, rather than the current login user, you can call web. currentuser to view

)

 

Any objects (spweb, splist, etc) that you create from this impersonated site collection will execute as the impersonated user.

Where to use-

This approach is useful to run any code which requires specific permissions to execute that code (like permission for reading a participant list), rather than having a full control access permission.

In such a case, service account can be created by specific access rights just sufficient enough to execute the code.

CAUTION-

Although impersonation provides a powerful new technique for managing security, it shocould be used with care to make sure that unwanted activity is not saved by users who shouldn't have the ability to impersonate.

 

 

 

Method 2 executing code with elevated privileges

Process

Method 1-

Elevation of Privilege is a new feature of that enables you to programmatically perform actions in code using an increased level of privilege. the Microsoft. sharepoint. spsecurity. runwithelevatedprivileges method enables you to supply a delegate that runs a subset of code in the context of an account with higher privileges than the current user.

For example:

1. Define a public method that acts simply as a front end to the method that does the "real" work.

Public void processmethod ()

{

Spsecurity. codetorunelevated elevatedmethod = new spsecurity. codetorunelevated (processmethodaselevated );

Spsecurity. runwithelevatedprivileges (elevatedmethod );

}

The Code uses a method from spsecurity to indicate the name of the method that will run with full control (basically using application pool account ).

In the first line, simply pass in the name of the method as the parameter. In the second line, you execute that method with elevated privileges.

2. Now create the method that does the real work. It is called by the first method (delegate), but executes with full control (under application pool account ):

Private void processmethodaselevated ()

{

// Code goes here to do our work

}

Method 2-

We can also implement this method by creating dummy delegate method within a code.

Spsecurity. runwithelevatedprivileges (

Delegate ()

{

// Code goes here to do our work

});

 

Where to use-

This approach can be used in scenarios to read or update site collection, site related objects using full control in event handlers, features or Web parts (I. e. Code being executed under SharePoint context.

CAUTION-

In this approach, we can't use any SharePoint objects that were created outside the method or else the impersonation won't work.

We also can't use anything like spcontrol. getcontextweb (context) because that also blows the impersonation out of the water.

Instead, we can tweak it like spsite site = new spsite (spcontrol. getcontextsite (context ). ID ). (use new spsite and use using for destruction after use) in this case, we are instantiating a new spsite object and only using the guid of the current site. i. e. recreation of the spsite object with new permissions.

Also, we shocould dispose of the spsite object created within the same () before exiting the scope, because that spsite will still have the SharePoint \ system identity even outside of the runwithelevatedprivileges () scope.

Runwithelevatedprivileges () has no effect when running in a standalone exe.

ArticleFrom: http://blog.csdn.net/babyan/archive/2008/11/12/3281438.aspx