Q 我吧
posts - 37,  comments - 62,  trackbacks - 12
公告

        在以前SharePoint 2003 中,impersonate 是一个可以在sps 环境中使用所有功能的至高无上选择,通过impersonate 就可以通过Object Modal 的方式操作SharePoint 的所有功能。但是到了Microsoft  Office SharePoint Server 2007 (moss2007 ,SharePoint Portal Server 2003 的后续版本) 这个又出现了新的变化,Impersonate 被丢弃了,而取而代之的是声称跟好的SPSecurity.RunWithElevatedPrivileges() , 它通过传入一个无返回,无输入参数的委托作为参数,对委托的方法以提升权限后的身份去运行,来达到通过Object Modal 方式访问Moss 中所有资源和功能的目的。
        在网上有些文章指出SPSecurity.RunWithElevatedPrivileges 这个方法实际上是用了IIS 中应用程序池中的用户去代替当前用户去运行,委托中的代码。这的确如此

但是这个方法并不是一步到位,直接的去使用应用程序池的用户,而是通过了一个所谓的“代理人”去完成这个事。无论在将Moss 的Web 应用程序部署为Windows 集成身份验证还是自定义的Forms 验证,在Moss 的所有列表库或文档库中的权限列表中,都会看到一个人,就是SHAREPOINT\System 这个用户,这个用户也是映射为当前的web 应用的网站集管理员,一般是第一个管理员。

Moss 2007  中,就是通过这个系统默认的管理帐号去模拟IIS 中应用程序池的用户,来达到对当前用户操作提升权限的效果。这就是说,其实在提升权限之后的一切操作都是以这个系统帐户(SHAREPOINT\system) 的身份去执行的,所以可以看到,若通过提升权限后进行的对文档库或列表进行添加、修改,在列表项的作者或修改人都会是系统帐户,而不是当前登录那个人的帐户,除非当前登录的人是网站集的管理员。
        因为,SPSecurity.RunWithElevatedPrivileges 是通过模拟一个固定的帐户去进行操作,所以就带来了另一个问题,就是当这“代理人”系统帐户对列表或文档没有权限的时候,就像上图那样,系统帐户对列表的权限是受限访问,SPSecurity.RunWithElevatedPrivileges 就会不起作用,而且在代码的层面上很难发现这个问题。所以在需要通过调用SPSecurity.RunWithElevatedPrivileges来提升权限操作的列表或文档库,都需要确保系统帐户(SHAREPOINT\system)在该列表或文档库中存在,并且这个帐户的权限必须为完全控制。

这样调用提升权限时才会成功。

posted on 2008-03-21 13:59 BlackAngel 阅读(...) 评论(...) 编辑 收藏