Rest 无法创建自定义用户权限以限制内容

我正在努力正确设置我的用户权限/特权/角色，以获得所需的行为

我正在使用MarkLogic 8和Roxy创建和部署应用程序

此应用程序具有不同的用户，这些用户的内容应仅限于单个用户。但他们也参与需要合作的项目

我已经看到了这一点，但仍然不能得到正确的

默认roxy应用程序用户角色：

<role>
  <role-name>${app-role}</role-name>
  <description>A role for users of the ${app-name} application</description>
  <role-names>
  </role-names>
  <permissions>
    <permission>
      <capability>execute</capability>
      <role-name>${app-role}</role-name>
    </permission>
    <permission>
      <capability>update</capability>
      <role-name>${app-role}</role-name>
    </permission>
    <permission>
      <capability>insert</capability>
      <role-name>${app-role}</role-name>
    </permission>
    <permission>
      <capability>read</capability>
      <role-name>${app-role}</role-name>
    </permission>
  </permissions>
  <collections>
  </collections>
  <privileges>
    <privilege>
      <privilege-name>xdmp:value</privilege-name>
    </privilege>
    <privilege>
      <privilege-name>xdmp:add-response-header</privilege-name>
    </privilege>
    <privilege>
      <privilege-name>xdmp:invoke</privilege-name>
    </privilege>
    <privilege>
      <privilege-name>xdmp:with-namespaces</privilege-name>
    </privilege>
  </privileges>
</role>

然后我们开始讨论rest阅读器应该是特权还是角色

因此，一个更具体的问题是：

---

访问roxy REST类型应用程序创建的REST端点所需的最小角色/权限集是多少？

我建议在这里采用以下方法：

使用应用程序角色执行应用程序，而不是从内容访问开始。因此，从该角色中删除默认权限，只需给它rest reader/rest writer权限，以及一些运行MLCP等的权限

下一步，确保REST扩展以及Roxy未直接部署的任何其他扩展都具有读取和执行文档的权限。考虑使用自定义代码、sql视图或未加载部署架构的架构创建的触发器和警报等。我们在slush marklogic节点中使用的更改权限功能可以作为如何处理此问题的示例：

一旦存在，为需要单独授予访问权限的内容的每个部分创建一个专用角色。如果您需要一组只能由一个用户访问的文档，则需要一个特定于用户的角色。如果您还有一组仅可由项目成员访问的文档，则还需要一个特定于项目的角色。如果您还需要区分读/写，请为每个角色设置两个角色（两个用户角色、两个项目角色）。这些角色将没有priv，并且不应该继承角色（除了write继承相应的read角色）

一旦拥有了读/写角色，就可以开始考虑如何在摄取时正确地将它们应用于文档权限。在这种复杂程度下，您可能希望避免默认权限，并显式选择文档权限。xdmp:document insert、MLCP和/v1/文档都具有显式的文档权限，因此您应该对这些权限有一定的控制

加成

关于Roxy的开箱即用ml配置文件的说明。它没有针对REST类型的应用程序进行适当的调优。这就是slush marklogic节点生成器修补ml配置的原因：

对REST api具有读取访问权限的最低要求是REST reader priv，对REST api具有更新访问权限的最低要求是REST writer priv。REST扩展是从模块数据库运行的，而不是从文件系统运行的，因此您还需要模块访问权限。上面提到的change_permissions函数为您修复了这一问题

无论如何，我的一般建议是使用应用程序角色执行应用程序，如前所述，并使用其他角色访问数据。任何想要使用应用程序的用户都应该继承应用程序角色以及一些其他角色，以提供适当数量的数据访问

---

嗯

您好，Grtjn，我已经更新了我的问题，使之更具体。。。希望你能分享你的观点？谢谢

<role>
  <role-name>sccss-user</role-name>
  <description>sccss default role</description>
  <role-names>
    <!-- TODO test which roles we really need -->
    <!--
    <role-name>alert-user</role-name>    
    <role-name>alert-internal</role-name> 
    <role-name>rest-admin</role-name> 
    <role-name>rest-writer-internal</role-name>
    <role-name>rest-reader</role-name> 
    <role-name>network-access</role-name>
    <role-name>qconsole-user</role-name>
    -->
    <!-- cluey app role for rest api access TODO replace with dedicated api user and role 

    <role-name>${app-role}</role-name>
    -->

  </role-names>
  <permissions>
  </permissions>
  <collections>
  </collections>
  <privileges>
    <!-- HK -->
    <!--
    <privilege>
      <privilege-name>any-uri</privilege-name>
    </privilege>
    -->
    <privilege>
      <privilege-name>devices-uri</privilege-name>
    </privilege>
    <privilege>
      <privilege-name>any-collection</privilege-name>
    </privilege>
    <!-- to make this role have acces to the REST API-->
    <privilege>
      <privilege-name>rest-reader</privilege-name>
    </privilege>
    <privilege>
      <privilege-name>rest-writer</privilege-name>
    </privilege>
    <!-- TODO test this
    <privilege>
      <privilege-name>xdmp:value</privilege-name>
    </privilege>
    <privilege>
      <privilege-name>xdmp:add-response-header</privilege-name>
    </privilege>
    <privilege>
      <privilege-name>xdmp:invoke</privilege-name>
    </privilege>
    <privilege>
      <privilege-name>xdmp:with-namespaces</privilege-name>
    </privilege>
  </privileges>
  -->
</role>

      <role-name>${app-role}</role-name>
      <!-- we need this to amp internal privileges-->
      <role-name>alert-user</role-name>    
      <role-name>alert-internal</role-name> 
      <role-name>rest-admin-internal</role-name>