与RunWithElevatedPrivileges一起返回SPListItem

Question

* *澄清。应用程序==站点定义。直接数据库访问是窗外 ** 我已经为SharePoint创建了一个应用程序，它利用了一些新的方法来编码列表访问。我以一种允许我以精确的方式控制数据交互的方式结构化了东西。

例如，我有一个名为Post的类，它有一些典型的元数据，如标题，摘要等。..

Post内部是一个名为NewPost的静态方法，它返回一个预先格式化的SPListItem，用于创建新帖子。

public static SPListItem NewPost(string Title,string Summary)
{
   Posts = CoreLists.Posts();
   var item = Posts.AddItem();
   var item["Alias"] = SPContext.Current.Web.CurrentUser.LoginName;
   return item;
}

你会注意到我正在通过一个名为CoreLists的帮助类获取SPList

public static class CoreLists
{
   public static SPList Posts()
   {
      return SPContext.Current.Web.GetList(SPContext.Current.Web.ServerRelativeUrl + "/lists/Posts");
   }
}

这使得一些很好的干净的数据方法。我遇到的是，我找不到一个像样的方法来调用这些方法 SPSecurity.RunWithElevatedPrivileges

SPSecurity.RunWithElevatedPrivileges 无法与返回块一起工作，所以当我尝试创建一个新的列表项时，它每次都失败。

我这么做是因为我把我的名单隐藏起来了。我希望人们只能通过我正在创建的UI访问它们。我想通过仅允许管理员创建项目来进一步锁定系统，并使用SecurityBits仅将项目编辑锁定到列表项目的创建者。

因此，所有列表项都是由系统帐户创建的，然后它们有一个名为Alias的字段，它允许我将该项目与用户匹配。

我是否需要重新考虑我的整个数据访问层？限制列表访问的决定是否与更清洁的数据访问层的愿望绝对冲突？

Answer 1

您使用 SPContext.Current.Web 在 SPSecurity.RunWithElevatedPrivileges 代表？

这是行不通的。拿东西 SPContext 为您提供具有 当前登录用户, ，而不是高架的。这意味着，如果您使用来自 SPContext, ，它们将在当前登录的用户的安全上下文中创建，而不是您认为正在创建它们的提升用户。

如果要使用sharepoint\system创建列表条目，则需要在SPSecurity中打开新的SPSite/SPWeb对象。RunWithElevatedPrivileges委托并与那些工作，而不是。

尝试改变这个:

   public static SPList Posts() 
   { 
      return SPContext.Current.Web.GetList(SPContext.Current.Web.ServerRelativeUrl + "/lists/Posts"); 
   } 

对此:

   public static SPList Posts() 
   { 
        using( var s = new SPSite(SPContext.Current.Site.ID)
        {
            using( var w = SPSite.OpenWeb(SPContext.Current.Web.ID)
            {
                 var postsList = w.Lists.TryGetList("Posts"); 
                 if( postsList != null )
                      return postsList;
                 else
                    /* do proper error handling */
            }
        }
    }

现在你的帖子。AddItem()应该使用正确提升的上下文创建列表条目。

阅读更多关于msdn上的特权提升的信息:http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsecurity.runwithelevatedprivileges.aspx

Answer 2

不要使用RWEP。你不需要它。

隐藏列表不需要特殊编码来访问。如果当前用户具有列表的权限，那么只需访问隐藏列表，就像任何其他列表一样。

如果当前用户没有列表权限，并且您希望通过代码代理更新，则应模拟系统帐户。此外，您不应将对象传递给安全边界。我建议创建传入数据层的数据传输对象。

Answer 3

vedrans点重新/安全性很好 - 如果您正在重写安全系统，您就会根据谷物工作。但您可能仍然希望利用安全性（和其他SharePoint福利），因此它不是完全 Menent，在SharePoint上构建一个应用程序。

对于基于SharePoint的架构 - 使用发布站点。这为您提供：

1. 列表等标准SharePoint UI - 这是Admin'HeactStage'视图。
2. 页面库与单独的主页/ ui - 这是“应用程序”界面。

   默认值（所有经过身份验证的用户）获取访问该站点的查看器访问权限。'admin'用户获得贡献者/显式权限，以列出。

   Punters只能通过应用程序界面中的自定义Web部件/代码访问站点数据。

Answer 4

你的整个概念是错误的。

如果您正在开发自己的UI和安全性，那么您为什么要使用SharePoint？使用SQL是更清洁的。

每次使用code sharepoint安全性中使用SPSecurity.RunWithElevatedPrivileges都会受到损害，因为您允许当前用户充当SharePoint \ System并访问所有内容。

btw您可以在SPSecurity.RunWithElevatedPrivileges下运行时设置“创建者”>

//First store current user
SPUser currentUser = SPContext.Current.Web.CurrentUser;

SPSecurity.RunWithElevatedPrivileges(delegate 
{
    using (SPSite elevatedSite = new SPSite(SPContext.Current.Site.Url))
    using (SPWeb targetWeb = elevatedSite.OpenWeb(webUrl))
    {
       //Code to get your item or to add a new one

       // Replace 'System Account' with current user
       item["Author"] = currentUser;
       item["Editor"] = currentUser;
       item.SystemUpdate();
    }
});

.

加法：

要避免任何进一步的误解：通过使用SQL，我不是意味着SharePoint数据库，而是其他一些不同的SQL数据库。为什么？由于您使用的是自定义UI，自定义安全检查，您的列表是隐藏的（因此用户不能使用SP OOTB功能，如排序，过滤等），搜索也不是一个选项 - >我真的没有看到使用SharePoint的任何优势作为数据存储。