Неспособность создать пользовательские разрешения для ограничения содержимого

Question

Я стараюсь правильно настроить права пользователя/привилегии/роли, чтобы получить нужное мне поведение.

Я использую MarkLogic 8 и Roxy для создания и развертывания приложения.

У этого приложения разные пользователи, у которых есть контент, который должен быть ограничен отдельным пользователем. Но они также участвуют в проектах, в которых им необходимо сотрудничать друг с другом.

Я видел это helpful blog и discussion on github issue 303, но все еще не смог это исправить.

По умолчанию роли пользователя 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> 

Мой заказ Роль:

<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> 

Я испытал и попробовал то, что описано в блоге выше, но с этими настройками я не получаю доступ к любому документ, по-видимому, не имеет доступа к расширению доступа. Если я даю своим пользователям {app-role}, он дает проблему, что пользователи могут видеть частный контент других пользователей ... потому что у всех пользователей есть роль «читателя-читателя» ... Поэтому мне нужно ограничить default-app, чтобы не использовать роль rest-reader и использовать привилегии читателей-читателей, но не могу заставить его работать ...

Один из вариантов, который я рассматриваю, заключается в использовании разрешений document-insert() для ограниченного контента, но это должно быть возможно с правильными ролями и привилегиями, если я смогу правильно настроить его, не так ли?

Сложение

В repsonse к ответу Grtjn в: ТНХ 4 ваши комментарии, я думаю, что я озадачен роли REST. Если я посмотрю на default roles в приложении roxy на git, то они выглядят пустыми, но когда я устанавливаю тип приложения roxy в качестве приложения REST, кажется, что он становится более сложным. Основная путаница в том, какие роли и привилегии мне нужны для второй (независимой) роли, чтобы иметь возможность использовать конечную точку REST? Каковы привилегии xdmp: (значение, add-response-header, invokes и т. Д. И т. Д.), Которые точно необходимы и необходимы? В моем примере для пользователя, чтобы иметь возможность получить доступ к REST API он/она нуждается в следующие роли:

 <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> 

И тогда мы получаем в дискуссию, если остальное-читатель должен быть привилегией или роль?

Так более конкретный вопрос:

Какова минимальная роль/набор привилегий я должен был бы получить доступ к конечной точке REST создать с помощью приложения Roxy типа остальное?

Answer 1

Я бы рекомендовал принимать следующий подход здесь:

Используйте приложение-роль для выполнения приложения, а не для доступа к содержимому, чтобы начать с. По этой причине удалите разрешения по умолчанию из этой роли и просто дайте ей привилегию для читателей/отдыхающих, и, возможно, некоторые привилегии для запуска MLCP и т. Д.

Затем убедитесь, что REST-расширения и все, что не установлено Roxy напрямую, получают чтение и выполнение разрешения документа. Подумайте о триггерах и предупреждениях, созданных с помощью специального кода, sql-views или схем, не загруженных с помощью схем развертывания и т. Д.Функция change_permissions, которую мы используем в slush-marklogic-узле, может служить примером того, как справиться с этим: https://github.com/marklogic/slush-marklogic-node/pull/298/files#diff-a529d1d70bd21866e1d12eda3a99f7b6R96

После создания отдельной роли для каждой части контента, которому должен быть предоставлен доступ отдельно. Если вам нужен набор документов для доступа только для одного пользователя, вам понадобится конкретная роль пользователя. Если у вас также есть набор документов, доступных только членам проекта, вам также нужна конкретная роль проекта. Если вам нужно различать чтение и запись, сделайте две роли для каждой (две пользовательские, две роли проекта). Эти роли не будут иметь привилегий и не должны наследовать роли (кроме записи, наследующей соответствующую роль чтения).

После того, как у вас есть роли чтения/записи, вы можете начать думать о том, как правильно их применять для разрешений документов при глотке. С такой степенью сложности вы можете отказаться от разрешений по умолчанию и явно выбрать права доступа к документам. xdmp: document-insert, MLCP и/v1/documents принимают явные разрешения на документы, поэтому вы должны иметь разумный контроль над ними.

Сложение

Примечание дальше вне Рокси файла окно мл-конфигурации. Он неправильно настроен для приложений типа REST. Вот почему генератор slush-marklogic-node патчирует ml-config: https://github.com/marklogic/slush-marklogic-node/blob/master/slushfile.js#L346

Голый минимум для доступа на чтение к REST api, является приватным для чтения и имеет доступ к обновлению для REST api, является rest-writer priv. Расширения REST выполняются из базы данных модулей, а не из файловой системы, поэтому вам необходим доступ к модулю для этого. Функция change_permissions, упомянутая выше, исправляет это для вас.

Как бы то ни было, моим общим советом было бы использовать роль приложения для выполнения приложения, как упоминалось ранее, и другие роли для доступа к данным. Любой пользователь, который хочет использовать приложение, должен наследовать роль приложения, а также некоторые другие роли, чтобы обеспечить соответствующий объем доступа к данным.

HTH!