我有一种强烈的直觉,认为应该像避瘟疫一样避免使用SharePoint的RunWithElevatedPrivileges
,但需要说服其他人确切地原因。以下是我的想法。
- 使用提升的特权生成新线程
- 阻塞其他操作,直到传递的委托返回
- 安全问题(以高特权级别运行,可能由最终用户执行)
- 其他问题?
我有一种强烈的直觉,认为应该像避瘟疫一样避免使用SharePoint的RunWithElevatedPrivileges
,但需要说服其他人确切地原因。以下是我的想法。
提升权限的原因可分为两类:
对于前者,最好使用SPSite模拟。后者是我使用RWEP的唯一原因。
要澄清的是,RWEP不会生成新线程。而是使用Win32 API将当前线程的身份还原回进程身份(关闭模拟),以运行权限提升的代码,然后切换回模拟以代表当前用户继续工作。这有几个影响:
正如Alex所说,一个SPSite的子级会继承其权限,而SPSite的权限是在创建时设置的。因此,即使您在CodeToRunElevated中引用了SPContext.Current.Site,它仍将以当前用户的权限进行操作。相反,您需要在提升块内创建和使用一个新的SPSite。
总结一下:在SharePoint之外模拟应用程序池,需要使用RWEP(运行Web请求的特权);在SharePoint内模拟应用程序池,需要使用SPSite模拟。
1) 大量使用RWEP是代码异味的一个很好指标。它很容易被滥用而导致严重的安全问题。许多开发人员不考虑用户可能会利用他们在“引擎盖下”间接获得的权力做什么。
举个例子:在使用RWEP之前调用ValidateFormDigest非常重要,以防止应用程序页面中的恶意请求。
2) SPWeb和SPSite对象需要在RWEP的上下文中创建。对于初学者来说很容易忘记,从而导致很多挫败感。
这个限制也意味着所有的工作和由这些对象创建的任何对象都必须在RWEP委托结束之前使用和完成。这是另一个常见的错误。
Keith Dahlby编写了扩展方法来解决这些问题,提供更强大和可读性更高的代码。
RWEP,像其他任何东西一样,都有优点和缺点。
如果您担心最终用户运行RWEP,那么您可能已经面临更大的问题,因为该代码已经安装在GAC上。
有时,您只需要坚持下去:考虑一个没有管理员权限的用户运行文档工作流程。 在此用户批准(或拒绝,无所谓)之后,您的工作流引擎应能够重新定义该SPListItem的特权。
我使用它,并发现它具有非常有用的功能。在我看来,我选择让用户运行我的代码并使该代码执行用户通常无法执行的操作。您可以锁定某些内容,但仍以非常受控制的方式让用户访问它。