When writing a webpart or eventhandler, the current user logging on to the website is a user with only common permissions such as viewing but not editing and adding permissions, the website has a webpart that uses the permissions of the users currently logged on to the website to add new records to a list or document library.CodeHowever, the currently logged-on user does not have the permission to add a new record to the list or document library. In this case, you need to do this in the webpart code.ArticleThis is the simulation I want to mention to improve the current user's permissions to run the Code with higher permissions.
The moss code is used to improve the permissions and simulate the permissions of the site administrator. In this process, the spsecurity. runwithelevatedprivileges in the object model of the user Moss is required. The spsecurity. runwithelevatedprivileges object simulates the security context creden。 of the current user in the Code as administrator permissions of the current site to run this code.
For example, in the first case:
// Simulate permission escalation
Spsecurity. runwithelevatedprivileges (delegate
{
// Create a specified site set
Using (spsite site = new spsite ("http: // moss "))
{
// Open the website
Using (spweb web = site. openweb ())
{
// Allows website updates
Web. allowunsafeupdates = true;
// Open the document library
Splist list = web. Lists [listname];
.............
Web. allowunsafeupdates = false;
}
}
});
In this case, the created spsite object will run the following method body as the site administrator (spsadmin) as a brand new identity, rather than the permissions of the current login user on the website.
For example, in the second case:
// Create a specified site set
Using (spsite site = new spsite ("http: // moss "))
{
// Simulate permission escalation
Spsecurity. runwithelevatedprivileges (delegate
{
// Open the website
Using (spweb web = site. openweb ())
{
// Allows website updates
Web. allowunsafeupdates = true;
// Open the document library
Splist list = web. Lists [listname];
.............
Web. allowunsafeupdates = false;
}
});
}
In this case, the created user security context permission is to run the following code method body based on the actual permissions of the currently logged-on user on this website, although the spweb object created in the Code opens the website in spsecurity. runwithelevatedprivileges runs in the method block where the permission is simulated, but spsecurity can be seen according to the code running result. the runwithelevatedprivileges object does not improve permissions.
These two methods demonstrate that the running effect of creating a site spsite object in the spsecurity. runwithelevatedprivileges object method block is completely different.
The above mentioned is to use the system administrator account and login user to execute the code. Of course, we can also specify the account for running the Code:
For example, in the third case:
Spsite sitecoll = spcontext. Current. Site;
Spweb site = spcontext. Current. Web;
Spuser user = site. Users [@ username@moss.com];
Spusertoken usertoken = user. usertoken;
Spsecurity. runwithelevatedprivileges (delegate (){
Using (spsite elevatedsitecoll = new spsite (sitecoll. ID, usertoken )){
Using (spweb elevatedsite = elevatedsitecoll. openweb (site. ID ))
{// Run as litware "Ken
String sitecollectionowner = elevatedsitecoll. Owner. Name;
}
}
});
In this way, the code runs with the "username@moss.com" permission.
Reference: http://www.cnblogs.com/netcai/archive/2008/09/11/1288897.html
Http://blog.csdn.net/iiboy/archive/2008/05/24/2477113.aspx