SharePoint 2007-运行时带有提升的特权-使用此功能的陷阱

提升的原因分为两类:

1. 您的代码需要在当前用户没有权限的SharePoint中执行操作。工作时应始终这样做 具有 SharePoint安全性,而不是作为“以防万一”的衡量标准,它表明您需要更好地了解安全状况。
2. 您的代码需要访问应用程序池标识可以访问但当前用户不能访问的外部资源(服务器文件系统、数据库、文件共享等)。

对于前者,使用 SPSite impersonation . 后者是我使用RWEP的唯一原因。

为了澄清,RWEP不会产生新的线程。相反,它使用win32 API将当前线程的标识还原回进程标识(关闭模拟)以运行提升的代码,然后重新打开模拟以代表当前用户恢复工作。这有几个含义:

1. 如果线程没有被模拟,RWEP什么也不做,因此它在计时器作业、Visual Studio工作流、控制台应用程序和通过stsadm(功能接收器)运行的代码中是无用的。
2. 对SharePoint的访问,假设您在代码中创建了一个新的SPSite,则将使用应用程序池(SharePoint\System)的权限执行。此帐户将具有对当前Web应用程序的完全访问权限,但是 不应该 具有场级权限,可以执行修改SPFarm属性或更改SSP等操作。
3. 跨代码执行边界使用识别对象(如spsite及其子对象)可能会导致一些真正的异常行为和种族条件。出于所有的意图和目的,认为这是不支持的。

正如亚历克斯所说,spsite的子级继承了spsite的权限,而spsite在创建时又设置了自己的权限。因此,spcontext.current.site的行为仍然具有当前用户的权限,即使您在代码中引用了该用户,也不例外。相反,您需要在提升的块中创建和使用一个新的spsite。

总结:rwep模拟SharePoint外的应用程序池,spsite模拟模拟SharePoint内的应用程序池。

1)大量使用RWEP是代码气味的良好指示。 它很容易被随意滥用,导致严重的安全问题。许多开发人员不考虑用户可以如何利用他们被间接赋予的“幕后”权力。

仅举一个例子:在将rwep用于 prevent malicious requests in application pages .

2)spweb和spsite对象需要在rwep上下文中创建。 对于新手开发人员来说,这很容易被遗忘,导致很多挫折。

此限制还意味着必须在RWEP委托结束之前使用并完成所有工作和这些对象创建的任何对象。这是另一个常见的错误。

基思·达尔比写过 extension methods 为了解决这些问题,提供更健壮和可读的代码。

RWEP和其他一切一样,都有利弊。

如果您担心最终用户运行RWEP,可能您已经遇到了更大的问题,因为GAC上已经安装了该代码。

有时候,你只需要坚持下去:考虑一个没有管理权限的用户,运行一个文档工作流。在这个用户批准(或拒绝,不重要)之后,您的工作流引擎应该能够重新定义SPListItem特权。

我使用它,发现它是非常有用的功能。在我看来,我选择让用户运行我的代码,让代码做一些用户通常不能做的事情。你可以锁定一些东西,并且仍然让用户以一种非常可控的方式访问它。