There are two ways to run a set of lines of code under administrator previlages.
Method 1:using runwithelivatedprevilages
this method runs under the Application Pool identity, which has site collection administrator privileges on all site collections hosted by that application pool.
NOTE: All the operations done inside this method should use a new SPSite Object. This means that the SPSite variables that are instantiated or created outside the subset code of this method can't be used for security elevation and it will result with the "Access denied error".
Wrong:
//SPSite Object created outside the RWEP Method
SPSite site = new SPSite("siteURL");
SPSecurity.RunWithElevatedPrivileges(delegate()
{
using (SPWeb web = site.OpenWeb())
{
string user = web.CurrentUser.Name;
//Operations that need high level access.
}
});
Correct:
SPSecurity.RunWithElevatedPrivileges(delegate()
{
//New SPSite object.
using (SPSite site = new SPSite(web.Site.ID))
{
//Do things by assuming the permission of the "system account".
}
});
Remember that, don’t use an object created outside of the RunWithElevatedPrivileges delegate within the delegate, and dispose all SPSite and SPWeb objects created within the delegate before the delegate completes.
And also dont use SPContext.Current.Web; to get SPWeb reference within the RunWithElevatedPrivileges.
Method 2: Using SPUserToken
Alternative impersonation technique to RunWithElevatedPrivileges() method:
We can either create a new SPSite instance from the existing SPSite Object, whose constructor will be provided by the "UserToken" of the System Account or we can assign the "UserToken" property of the SPSite object, see the below code snippet.
//Creating a SPUsertoken object.
SPUserToken saUserToken = SPContext.Current.Site.SystemAccount.UserToken;
//passing to the constructor of the SPSite
SPSite spSite=new SPSite("siteURL",saUserToken);
or
SPUserToken saUserToken = SPContext.Current.Site.SystemAccount.UserToken;
SPSite spSite=new SPSite("siteURL");
//assigning the UserToken property of SpSite.
spSite.UserToken= saUserToken;
Bellow is example for UserToken
SPUserToken saUserToken = SPContext.Current.Site.SystemAccount.UserToken;
using (var site3 = new SPSite(site.OpenWeb().Url, saUserToken ))
{
// This code runs under the security context of the SHAREPOINT system
// for all objects accessed through the "site" reference. Note that it’s a
// different reference than SPContext.Current.Site.
using (var elevatedWeb = site3.OpenWeb())
{
// Perform actions as SYSTEM here
SPUser spUser = elevatedWeb.EnsureUser(username);
SPGroup spGroup = elevatedWeb.SiteGroups["Partners"];
if (spGroup != null)
{
site3.AllowUnsafeUpdates = true;
spGroup.AddUser(spUser.ToString(), spUser.Email.ToString(), spUser.Name.ToString(), spUser.Notes.ToString());
site3.AllowUnsafeUpdates = false;
}
}
}
Performance impact with RunWithElevatedPrivileges creates a new thread with the App Pool's credentials, blocking your current thread until it finishes.
Method 1:using runwithelivatedprevilages
this method runs under the Application Pool identity, which has site collection administrator privileges on all site collections hosted by that application pool.
NOTE: All the operations done inside this method should use a new SPSite Object. This means that the SPSite variables that are instantiated or created outside the subset code of this method can't be used for security elevation and it will result with the "Access denied error".
Wrong:
//SPSite Object created outside the RWEP Method
SPSite site = new SPSite("siteURL");
SPSecurity.RunWithElevatedPrivileges(delegate()
{
using (SPWeb web = site.OpenWeb())
{
string user = web.CurrentUser.Name;
//Operations that need high level access.
}
});
Correct:
SPSecurity.RunWithElevatedPrivileges(delegate()
{
//New SPSite object.
using (SPSite site = new SPSite(web.Site.ID))
{
//Do things by assuming the permission of the "system account".
}
});
Remember that, don’t use an object created outside of the RunWithElevatedPrivileges delegate within the delegate, and dispose all SPSite and SPWeb objects created within the delegate before the delegate completes.
And also dont use SPContext.Current.Web; to get SPWeb reference within the RunWithElevatedPrivileges.
Method 2: Using SPUserToken
Alternative impersonation technique to RunWithElevatedPrivileges() method:
We can either create a new SPSite instance from the existing SPSite Object, whose constructor will be provided by the "UserToken" of the System Account or we can assign the "UserToken" property of the SPSite object, see the below code snippet.
//Creating a SPUsertoken object.
SPUserToken saUserToken = SPContext.Current.Site.SystemAccount.UserToken;
//passing to the constructor of the SPSite
SPSite spSite=new SPSite("siteURL",saUserToken);
or
SPUserToken saUserToken = SPContext.Current.Site.SystemAccount.UserToken;
SPSite spSite=new SPSite("siteURL");
//assigning the UserToken property of SpSite.
spSite.UserToken= saUserToken;
Bellow is example for UserToken
SPUserToken saUserToken = SPContext.Current.Site.SystemAccount.UserToken;
{
// This code runs under the security context of the SHAREPOINT system
// for all objects accessed through the "site" reference. Note that it’s a
// different reference than SPContext.Current.Site.
using (var elevatedWeb = site3.OpenWeb())
{
// Perform actions as SYSTEM here
SPUser spUser = elevatedWeb.EnsureUser(username);
SPGroup spGroup = elevatedWeb.SiteGroups["Partners"];
if (spGroup != null)
{
site3.AllowUnsafeUpdates = true;
spGroup.AddUser(spUser.ToString(), spUser.Email.ToString(), spUser.Name.ToString(), spUser.Notes.ToString());
site3.AllowUnsafeUpdates = false;
}
}
}
Performance impact with RunWithElevatedPrivileges creates a new thread with the App Pool's credentials, blocking your current thread until it finishes.
No comments:
Post a Comment