Sharepoint 2007 匿名账户提升权限修改列表
2013-01-08 11:18
477 查看
在进行SharePoint编程时,有时需要修改List中的某一个Item,但是当前的登录用户没有权限对该List修改,那么在编程时一般可以通过两种方式来进行,下面就是这两种方法的介绍:
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 effective security mechanism.
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 ----
方法一 Executing code as another named user
Process
When we create a SharePoint site programmatically using the
Microsoft.SharePoint namespace, 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 from
the Microsoft.SharePoint.SPUser object. 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一般可以使用 SHAREPOINT/system
SPUserToken token = user.UserToken;
SPSite impersonatedSiteCollection = new SPSite("SiteCollection_Url", token);
(........ 修改前使用web.AllowUnsafeUpdates = true; 修改结束之后在赋值为false
注意此时的用户已经是SHAREPOINT/system,而不是当前登录用户,可以调用web.CurrentUser查看
)
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 particular 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 should be used with care to make sure that unwanted activity is not performed by users who shouldn't have the ability to impersonate.
方法二 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).
(注意使用new SPSite, 并使用using 以便使用完毕后销毁)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 should dispose of the SPSite object created within the RunWithElevatedPrivileges() 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.
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 effective security mechanism.
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 ----
方法一 Executing code as another named user
Process
When we create a SharePoint site programmatically using the
Microsoft.SharePoint namespace, 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 from
the Microsoft.SharePoint.SPUser object. 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一般可以使用 SHAREPOINT/system
SPUserToken token = user.UserToken;
SPSite impersonatedSiteCollection = new SPSite("SiteCollection_Url", token);
(........ 修改前使用web.AllowUnsafeUpdates = true; 修改结束之后在赋值为false
注意此时的用户已经是SHAREPOINT/system,而不是当前登录用户,可以调用web.CurrentUser查看
)
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 particular 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 should be used with care to make sure that unwanted activity is not performed by users who shouldn't have the ability to impersonate.
方法二 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).
(注意使用new SPSite, 并使用using 以便使用完毕后销毁)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 should dispose of the SPSite object created within the RunWithElevatedPrivileges() 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.
相关文章推荐
- sharepoint 代码提升匿名用户、只读用户修改列表的权限
- sharepoint 2007 列表的内部名称修改
- 好神奇的代码,可以让匿名用户对特定SharePoint 列表拥用添加列表项的权限哦
- SharePoint 2013 自定义模板页后在列表里修改不了视图
- 关于MOSS 2007匿名访问权限的测试
- 一步一步SharePoint 2007之十九:解决实现注册用户后,自动具备访问网站的权限的问题(1)——配置Provider
- ASP.NET C#.NET 通用权限管理系统组件2011年01月BUG修改情况列表清单
- SharePoint 2007中 利用ListViewWebpart 和DataViewWebpart 跨站点 调用列表或者文档库
- sharepoint 2010 提升SPWeb权限
- SharePoint 2007 单列表模糊查询SPD定制
- vsftp服务器实现匿名用户上传、修改权限和一些设置
- 设置sharepoint列表和库匿名访问
- SharePoint 2007 在Windows Server 2008上列表Open with Windows Explorer失效 解决
- SharePoint 2010 权限提升-SPSecurity.RunWithElevatedPrivileges method (Microsoft.SharePoint)
- 通过代码解决SharePoint列表视图权限分配问题
- 教你如何修改win7系统的账户权限
- Sharepoint 2010:基于当前用户判断访问列表项目的权限 --Determine access to SPListItem based on a Current User
- ThinkPHP Authority.class.php 修改待验证的权限$name如果权限列表里面不存在则默认有该权限
- 修改sharepoint列表样式
- 一步一步SharePoint 2007之十九:解决实现注册用户后,自动具备访问网站的权限的问题(1)——配置Provider