4

请注意，我说的是将我的代码注入 SharePoint 服务器端（通过包/加载项等），而不是使用Microsoft.SharePoint.dllWeb 服务或 Web 服务来访问 SharePoint。

所以我的问题是，我需要自定义文档库的工作方式，包括自定义权限管理。我一直在浏览Microsoft.SharePoint.dll分析其工作的内部结构。以下是我的观察：

  1. SPDocumentLibrary提供管理文档库的核心逻辑。然而，它WebPart本身并不是一个。
  2. 文档库的实际 Web 部件呈现可能由ListViewWebPart派生类处理。
  3. 实际上有一个SPPictureLibrary类让我假设可以继承SPDocumentLibrary类以在文档库上提供自定义行为。
  4. WebPartAdder.SiteWebPartGalleryProvider以某种方式连接SPDocumentLibrary到它的WebPart内部Microsoft.SharePoint.WebPartPages.WebPartAdder.AddSources方法。

现在所有这些都是客户端，这些都不会发生在 SharePoint 服务器本身 (afaik) 上。但是我在SPSecurableObject那个SPDocumentLibrary/SPList覆盖上看到了可覆盖的方法，特别是：

  1. CheckPermissions
  2. GetUserEffectivePermissionInfo
  3. GetUserEffectivePermissions
  4. EffectiveBasePermissions， ETC。

我真正想做的是能够在 SharePoint 服务器内部覆盖CheckPermissions/EffectiveBasePermissions以SPDocumentLibrary注入我的自定义逻辑。

我现在将我的研究转移到 SharePoint 服务器端 dll 并理解它们。但我很想就这是否可行/指向正确的方向获得一些专家意见。Microsoft 的标志（特别是考虑将 ASP.NET 2.0 / ASP.NET MVC 作为基准）是可扩展性/提供程序框架。它们为开箱即用的“事物”提供了出色的提供者，但您可以通过继承/实现某些东西来替换默认提供者来创建类。所以：

  1. 我可以注入 SharePoint 服务器端吗？我理想的解决方案是创建一个SPDocumentLibrary派生类（服务器端），并将其注入，以便在任何时候实例化文档库时，都会创建我的类对象（而不是SPDocumentLibrary，假设这也是服务器端的类。我仍然需要“反映” SharePoint 服务器端类）。
  2. 如果 1) 不正确，我是否可以创建一个自定义WebPart以使用 SharePoint 文档库，使其具有原生文档库的感觉，但SPDocumentLibrary在访问该 Web 部件时仍允许我使用派生类（请再次注意，我所有的讨论都围绕 SharePoint 服务器端，即我的代码在 SharePoint 的地址空间/w3wp 进程中执行）。
  3. 为什么我们有逻辑SPSite.EffectiveBasePermissions。我的意思是它应该是 CSOM，它应该只负责对服务器返回/发送的内容进行序列化/反序列化。但是，我在这个被覆盖的属性中看到了围绕权限推导的复杂逻辑。
  4. 如果 1) 和 2) 都是无操作（字面意思是:)），在 SharePoint 基于这些权限采取任何操作之前，我是否可以在 SharePoint 的地址空间中操作时操纵 SharePoint 有效权限。

我知道这是一个很长的问题，但希望我的研究做得很好。

4

1 回答 1

2

我认为您在 SharePoint 中没有那种级别的控制。

不确定您是否查看过 SharePoint 事件选项。您可以将逻辑添加为 SharePoint 事件，而不是创建自己的类来添加逻辑。您可以订阅相关事件并相应地添加逻辑。例如，您可以根据自定义逻辑取消更新。但是，我认为您不能自定义基本权限逻辑。

SPList 有一个方法“CheckPermissions”，该方法又调用基类 (SPSecurableObject) 的“CheckPermissions”。但是，我怀疑是否有可能创建自己的子类，覆盖相关方法并接管权限逻辑。它是 SharePoint 非常核心的东西，我认为它不应该被定制。

于 2017-10-22T01:45:56.037 回答