8

我有一种强烈的直觉，RunWithElevatedPrivileges应该像瘟疫一样避免使用 SharePoint，但需要说服其他人确切原因。这就是我所拥有的。

  • 产生一个具有提升权限的新线程
  • 阻塞其他操作，直到传递的委托返回
  • 安全问题（可能由最终用户以高级别的权限运行）
  • 其他的？
4

4 回答 4

15

提升的原因分为两类：

  1. 您的代码需要在 SharePoint 中执行当前用户没有权限的操作。这应始终在使用SharePoint 安全性时完成，而不是作为一种“以防万一”措施，表明您需要更好地了解您的安全状况。
  2. 您的代码需要访问应用程序池身份可以访问但当前用户不能访问的外部资源（服务器文件系统、数据库、文件共享等）。

对于前者，最好使用SPSite impersonation。后者是我使用 RWEP 的唯一原因。

澄清一下，RWEP 不会产生新线程。相反，它使用 Win32 API 将当前线程的身份恢复为进程身份（关闭模拟）以运行提升的代码，然后重新打开模拟以代表当前用户恢复工作。这有几个含义：

  1. 如果线程没有被模拟，RWEP 什么都不做，因此它在计时器作业、Visual Studio 工作流、控制台应用程序和通过 stsadm（功能接收器）运行的代码中毫无用处。
  2. 假设您在 CodeToRunElevated 中创建了一个新的 SPSite，将使用应用程序池 (SHAREPOINT\system) 的权限访问 SharePoint。此帐户将拥有对当前 Web 应用程序的完全访问权限，但不应拥有服务器场级别的权限来执行修改 SPFarm 属性或更改 SSP 等操作。
  3. 在 CodeToRunElevated 的执行边界上使用身份感知对象（如 SPSite 及其子对象）可能会导致一些非常时髦的行为和竞争条件。出于所有意图和目的，认为这是不受支持的。

正如 Alex 所说，SPSite 的子级从 SPSite 继承其权限，而 SPSite 在创建时又设置了权限。因此，即使您在 CodeToRunElevated 中引用它，SPContext.Current.Site 仍将以当前用户的权限运行。相反，您需要在提升的块内创建和使用新的 SPSite。

总结一下：RWEP 模拟 SharePoint 外部的应用程序池，SPSite 模拟模拟 SharePoint 内部的应用程序池。

于 2009-10-06T19:01:31.227 回答
4

1) 大量使用 RWEP 是代码异味的一个很好的迹象。它很容易被滥用而不加考虑，从而导致严重的安全问题。许多开发人员没有考虑用户可以使用“幕后”间接获得的权力做什么。

仅举一个例子：在使用 RWEP 之前调用 ValidateFormDigest 很重要，以防止应用程序页面中的恶意请求。

2) SPWeb 和 SPSite 对象需要在 RWEP 的上下文中创建。这对于新手开发人员来说很容易忘记，从而导致很多挫败感。

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

Keith Dahlby 编写了扩展方法来解决这些问题，提供更健壮和可读的代码。

于 2009-10-06T14:49:56.287 回答
2

RWEP 和其他一切一样，有利也有弊。

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

有时，您只需要坚持下去：考虑一个没有管理员权限的用户，正在运行文档工作流程。在此用户批准（或拒绝，没关系）之后，您的工作流引擎应该能够重新定义该 SPListItem 权限。

于 2009-10-06T14:37:17.640 回答
0

我使用它，并发现它是非常有用的功能。在我看来，我选择让用户运行我的代码并让该代码执行用户通常无法执行的操作。您可以锁定某些内容，并且仍然让用户以非常可控的方式访问它。

于 2009-10-06T14:47:07.707 回答