Открыть меню
Toggle preferences menu
Открыть персональное меню
Вы не представились системе
Your IP address will be publicly visible if you make any edits.

Доступ к данным и приложениям. Роли: различия между версиями

Материал из Платформа Эра. Документации
 
(не показано 14 промежуточных версий этого же участника)
Строка 4: Строка 4:
'''Роль''' – это набор прав доступа пользователя. Каждый пользователь системы обладает набором ролей (назначенных ему напрямую либо через группы, в которые он входит). Набор ролей пользователя определяет перечень доступных ему приложений, состав этих приложений, права доступа на чтение и запись к классам, строкам и полям.
'''Роль''' – это набор прав доступа пользователя. Каждый пользователь системы обладает набором ролей (назначенных ему напрямую либо через группы, в которые он входит). Набор ролей пользователя определяет перечень доступных ему приложений, состав этих приложений, права доступа на чтение и запись к классам, строкам и полям.


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


Создаваемая роль может быть унаследована от существующей роли. В таком случае, права родительской роли будут распространяться и на дочернюю, но не наоборот.
Создаваемая роль может быть унаследована от существующей роли. В таком случае, права родительской роли будут распространяться и на дочернюю, но не наоборот.
Строка 29: Строка 29:
|}
|}


= Ролевой доступ к классу. =
= Использование ролей в настройках приложения =
Для класса можно указать список ролей, для которых класс доступен на чтение и запись (свойства readRoles и writeRoles на вкладке Security). Разрешение записи приводит к автоматическому разрешению чтения. Если оба списка пусты, все роли пакета получают полный доступ к классу. Если задан только список ролей для записи, все роли пакета получают доступ на чтение, а перечисленные в списке роли - на чтение и запись. Если задан только список ролей для чтения, никто не получит прав на запись.  
Доступ к приложению, или отдельным его контролам может быть ограничен с помощью ролей.


Пример класса, который доступен на чтение ролям zoo_admin, zoo_user и zoo_guest, а на запись - только zoo_admin и zoo_user:
В параметрах приложения и элемента Toolbox, можно заполнить массив roles. В таком случае, данное приложение, или элементы Toolbox будут '''видны''' только указанным ролям. Данная настройка влияет только на отображение, она не ограничивает доступ пользователей к данным любым другим способом (например, через API, или через присоединенные классы в других контролах).


Если массив ролей пустой, то такое приложение (или элемент Toolbox) будет доступно всем пользователям системы.
= Использование ролей в настройках класса =
В системе классов присутствует гибкий механизм настройки прав доступа.
Реализуется три уровня ограничения:
* Ограничение доступа к данным класса целиком (readRoles, writeRoles, readByIDRoles)
* Ограничение доступа к конкретным записям (объектам) класса (readFilter, writeFilter)
* Ограничение доступа к конкретным свойствам (полям) класса (readFilter и writeFilter в коллекции свойств data)
Настройки ограничения доступа к данным класса и к конкретным записям, находятся в редакторе класса, на вкладке [[Хранение данных. Классы|Security]].
Настройки ограничения доступа к свойствам (полям) класса, находятся в [[Хранение данных. Классы. Поля и действия|редакторе элементов коллекции свойств data]].
Разберем все три уровня ограничений и доступные для них настройки.
== Ограничение доступа к данным класса целиком ==
[[Файл:Class roles access.png|мини|Настройки доступа к данным класса]]
Общее ограничение доступа к данным класса реализуется тремя параметрами:
* readRoles - роли, которым разрешено чтение
* writeRoles - роли, которым разрешена запись (Insert, Update)
* readByIDRoles - роли, которым запрещено общее чтение, но разрешено чтение конкретных записей по идентификатору (например, для присоединенных классов)
Если у класса все списки пусты – все роли пакета имеют разрешение на чтение и запись. Если задан только список ролей для записи, все роли пакета получают доступ на чтение, а перечисленные в списке роли - на чтение и запись. Если задан только список ролей для чтения, никто не получит прав на запись.
== Ограничение доступа к конкретным записям класса ==
[[Файл:ReadFilter.png|мини|Блог параметров readFilter]]
Для ограничения доступа к конкретным записям используются блоки параметров readFilter (для ограничений доступа на чтение) и writeFilter (для ограничений доступа на запись) в редакторе класса. По принципу работы и настройки эти блоки идентичны, поэтому рассмотрим пример их настройки на базе readFilter.
Настройки фильтра определяются четырьмя основными параметрами, а также могут быть определны произвольным JSON:
* '''roles''' - список ролей, которым доступны '''все''' записи класса, т.е. <u>фильтр будет игнорироваться</u>
* '''userPropertyNames''' - список полей с типом root/iam/RootUser, по которым будет определяться принадлежность записи к конкретному пользователю. В случае настройки этого фильтра, каждый пользователь будет видеть только "свои" записи
* '''subordinatedPropertyNames''' - список полей с типом root/iam/RootUser, по которым будет определяться принадлежность записи к подчиненным текущего пользователя. В случае настройки этого фильтра, каждый пользователь будет видеть только записи "своих подчиненных"
* '''mandatePropertyName''' - имя поля, содержащего информацию о необходимом мандате доступа. Простыми словами - уровень доступа пользователя, требуемый для работы с этими данными. Уровень доступа пользователя определяется значением поля security.mandate в учетной записи пользователя, всех его групп и ролей.
* '''customFilter''' - JSON, описывающий произвольный механизм фильтрации
Готовый фильтр после формирования сохраняется в параметр result. Его можно использовать для изучения и дальнейшего составления собственного фильтра для customFilter.
== Ограничение доступа к конкретным свойствам класса ==
[[Файл:DataProperty Security.png|мини|Вкладка Security]]
Для ограничения доступа к конкретным свойствам (полям) используется аналогичный механизм readFilter/writeFilter, но уже в коллекции свойств data, на вкладке Security.
Если для поля класса заданы фильтры чтения и записи (формат аналогичен фильтрам для строк), то при чтении будет выполняться автоматическая маскировка (скрытие) недоступных полей, а при записи недоступные поля будут игнорироваться.
= Примеры организации ограничения доступа =
== Ролевой доступ к классу ==
[[Файл:Ролевой доступ к классу.png|мини|Пример в редакторе класса]]
Для класса можно указать список ролей, для которых класс доступен на чтение и запись (свойства readRoles и writeRoles на вкладке Security). Разрешение записи приводит к автоматическому разрешению чтения. Если оба списка пусты, все роли пакета получают полный доступ к классу.  <blockquote>Если задан только список ролей для записи, все роли пакета получают доступ на чтение, а перечисленные в списке роли - на чтение и запись. Если задан только список ролей для чтения, никто не получит прав на запись. </blockquote>Пример класса, который доступен на чтение ролям zoo_admin, zoo_user и zoo_guest, а на запись - только zoo_admin и zoo_user:
<syntaxhighlight lang="JavaScript">
readRoles: ["zoo_guest"]
readRoles: ["zoo_guest"]
 
</syntaxhighlight>
<syntaxhighlight lang="JavaScript">
writeRoles: ["zoo_admin", "zoo_user"]  
writeRoles: ["zoo_admin", "zoo_user"]  
 
</syntaxhighlight>
Ролевой доступ к классам приводит к формированию списка routes для каждой роли в процессе активации пакета. Поэтому поля readRoles и writeRoles могут содержать только роли текущего пакета. Для обеспечения доступа к классам других пакетов нужно задавать необходимые routes для соответствующих ролей
Ролевой доступ к классам приводит к формированию списка routes для каждой роли в процессе активации пакета. Поэтому поля readRoles и writeRoles могут содержать только роли текущего пакета. Для обеспечения доступа к классам других пакетов нужно задавать необходимые routes для соответствующих ролей


= Ограничение доступа к строкам (объектам) класса. =
== Ограничение доступа к строкам (объектам) класса ==
[[Файл:ReadFilter example.png|мини|Пример в редакторе класса]]
Обеспечивается условиями фильтра для чтения и записи (группы readFilter и writeFilter на вкладке Security) с поддержкой специальной функции $USER. Реализация наиболее распространенных кейсов (доступ по ролям, фильтрация "своих" строк по указанным полям, фильтрация строк подчиненных пользователей и простейшая мандатная правовая модель) сведена к перечислению ролей (свойство roles) и полей (свойства userPropertyNames, subordinatedPropertyNames, mandatePropertyName), остальные кейсы решаются явным указанием произвольного фильтра (свойство customFilter).  
Обеспечивается условиями фильтра для чтения и записи (группы readFilter и writeFilter на вкладке Security) с поддержкой специальной функции $USER. Реализация наиболее распространенных кейсов (доступ по ролям, фильтрация "своих" строк по указанным полям, фильтрация строк подчиненных пользователей и простейшая мандатная правовая модель) сведена к перечислению ролей (свойство roles) и полей (свойства userPropertyNames, subordinatedPropertyNames, mandatePropertyName), остальные кейсы решаются явным указанием произвольного фильтра (свойство customFilter).  


Пример класса, который полностью доступен на чтение роли zoo_admin, а остальным ролям - только выборка "своих" строк по одному из полей author_id или worker_id:  
Пример класса, который полностью доступен на чтение роли zoo_admin, а остальным ролям - только выборка "своих" строк по одному из полей author_id или worker_id:  
 
<syntaxhighlight lang="JavaScript">
readFilter: { roles: ["zoo_admin"], userPropertyNames: ["author_id", "worker_id"], }  
readFilter: { roles: ["zoo_admin"], userPropertyNames: ["author_id", "worker_id"], }  
 
</syntaxhighlight>
Итоговый фильтр формируется системой автоматически (логическим оператором or) и доступен для контроля на карточке класса:  
Итоговый фильтр формируется системой автоматически (логическим оператором or) и доступен для контроля на карточке класса:  
 
<syntaxhighlight lang="JavaScript">
[ "or", [ "in", "zoo_admin", [ "$USER", "ROLES" ] ], [ "or", [ "==", [ "property", "author_id" ], [ "$USER", "id" ] ], [ "==", [ "property", "worker_id" ], [ "$USER", "id" ] ] ] ]
[ "or", [ "in", "zoo_admin", [ "$USER", "ROLES" ] ], [ "or", [ "==", [ "property", "author_id" ], [ "$USER", "id" ] ], [ "==", [ "property", "worker_id" ], [ "$USER", "id" ] ] ] ]
</syntaxhighlight>


Полный перечень доступных функций приведен в документации (Сущности - design - class - Специальные функции фильтра). Предусмотрен доступ к свойствам учетной записи пользователя, его группам и ролям, подчиненным пользователям, а также агрегация произвольного поля security для поиска необходимого значения мандата
Полный перечень доступных функций приведен в [https://vendor.era-platform.ru/docs/era/latest/api/rest/v1/model/overview/index.html#read_collection_filter документации на портале vendor]. Предусмотрен доступ к свойствам учетной записи пользователя, его группам и ролям, подчиненным пользователям, а также агрегация произвольного поля security для поиска необходимого значения мандата


= Ограничение доступа к столбцам (полям) класса. =
== Ограничение доступа к столбцам (полям) класса ==
Если для поля класса заданы фильтры чтения и записи (формат аналогичен фильтрам для строк), то при чтении будет выполняться автоматическая маскировка (скрытие) недоступных полей, а при записи недоступные поля будут игнорироваться.  
[[Файл:DataProperty Security example.png|мини|Пример в редакторе свойства класса]]
 
Пример поля, которое доступно для чтения и записи только конкретным ролям:


Пример поля, которое доступно для чтения и записи только конкретным ролям: <syntaxhighlight lang="JavaScript">
readFilter: { roles: ["zoo_admin", "zoo_user"], },  
readFilter: { roles: ["zoo_admin", "zoo_user"], },  
 
</syntaxhighlight>
<syntaxhighlight lang="JavaScript">
writeFilter: { roles: ["zoo_admin"], }  
writeFilter: { roles: ["zoo_admin"], }  
</syntaxhighlight>


Пример поля, которое доступно для записи только для "своих" (по полю author_id) строк:  
Пример поля, которое доступно для записи только для "своих" (по полю author_id) строк:  
 
<syntaxhighlight lang="JavaScript">
writeFilter: { userPropertyNames: ["author_id"], }  
writeFilter: { userPropertyNames: ["author_id"], }  
</syntaxhighlight>


Пример поля, которое доступно для записи только для незавершенных (по полю finished) задач:  
Пример поля, которое доступно для записи только для незавершенных (по полю finished) задач:  
 
<syntaxhighlight lang="JavaScript">
writeFilter: { customFilter: ["==", ["property", "finished"], ["const", false]] }  
writeFilter: { customFilter: ["==", ["property", "finished"], ["const", false]] }  
</syntaxhighlight>


Условия visibility и readOnly для полей на элементах управления (в частности, в таблицах и карточках) необходимо задавать отдельно. Вполне вероятно, что в последующих версиях условия фильтрации полей будут приводить к их автоматическому скрытию или переводу в режим readOnly.
Условия visibility и readOnly для полей на элементах управления (в частности, в таблицах и карточках) необходимо задавать отдельно. Вполне вероятно, что в последующих версиях условия фильтрации полей будут приводить к их автоматическому скрытию или переводу в режим readOnly.


= Мандатная правовая модель. =
== Мандатная правовая модель ==
В некоторых случаях бывает удобно от ролевой модели безопасности перейти к мандатной. Для этого в свойствах пользователей, групп и ролей предназначено поле security, которое может иметь произвольную структуру (например, security: { "mandate": 5 }). Для обращения к мандату пользователя в фильтре необходимо использовать конструкцию вида ["$USER", "security", "mandate"], а для поиска минимального либо максимального значения мандата с учетом пользователя, всех его групп и ролей - ["$USER", "DEEP", "MIN", "security", "mandate"] либо ["$USER", "DEEP", "MAX", "security", "mandate"]. Таким образом, если одно из полей класса содержит числовое значение необходимого мандата доступа, в условиях фильтров (как для строк, так и для столбцов) можно выполнить необходимую проверку (как правило - значение мандата пользователя должно быть не менее, чем значение мандата объекта).  
В некоторых случаях бывает удобно от ролевой модели безопасности перейти к мандатной. Для этого в свойствах пользователей, групп и ролей предназначено поле security, которое может иметь произвольную структуру (например, security: { "mandate": 5 }). Для обращения к мандату пользователя в фильтре необходимо использовать конструкцию вида ["$USER", "security", "mandate"], а для поиска минимального либо максимального значения мандата с учетом пользователя, всех его групп и ролей - ["$USER", "DEEP", "MIN", "security", "mandate"] либо ["$USER", "DEEP", "MAX", "security", "mandate"]. Таким образом, если одно из полей класса содержит числовое значение необходимого мандата доступа, в условиях фильтров (как для строк, так и для столбцов) можно выполнить необходимую проверку (как правило - значение мандата пользователя должно быть не менее, чем значение мандата объекта).  


Пользователю доступны строки, значение поля accessLevel которых меньше или равно максимальному значению security.accessLevel пользователя, его групп и ролей:  
Пользователю доступны строки, значение поля accessLevel которых меньше или равно максимальному значению security.accessLevel пользователя, его групп и ролей:
 
<syntaxhighlight lang="JavaScript">
readFilter: { mandatePropertyName: "accessLevel" }  
readFilter: { mandatePropertyName: "accessLevel" }
 
</syntaxhighlight>
Сформированный системой итоговый фильтр:  
Сформированный системой итоговый фильтр:  
 
<syntaxhighlight lang="JavaScript">
[ ">=", [ "$USER", "DEEP", "MAX", "security", "accessLevel" ], [ "property", "accessLevel" ] ]
[ ">=", [ "$USER", "DEEP", "MAX", "security", "accessLevel" ], [ "property", "accessLevel" ] ]
 
</syntaxhighlight>
Богатая функциональность и гибкость механизма фильтров (описанная в предыдущих разделах) позволяет строить достаточно сложные схемы разграничения прав доступа на пересечении четырех размерностей: чтение-запись, классы, строки, столбцы.
Богатая функциональность и гибкость механизма фильтров (описанная в предыдущих разделах) позволяет строить достаточно сложные схемы разграничения прав доступа на пересечении четырех размерностей: чтение-запись, классы, строки, столбцы.


= Подчиненность пользователей. =
== Подчиненность пользователей ==
Для отображения пользователю строк, поле worker_id которых содержит идентификатор любого подчиненного ему пользователя (либо ему подчинены все), необходимо задать следующий фильтр:  
Для отображения пользователю строк, поле worker_id которых содержит идентификатор любого подчиненного ему пользователя (либо ему подчинены все), необходимо задать следующий фильтр:  
 
<syntaxhighlight lang="JavaScript">
readFilter: { subordinatedPropertyNames: ["worker_id"], }  
readFilter: { subordinatedPropertyNames: ["worker_id"], }
 
</syntaxhighlight>
Сформированный системой итоговый фильтр:
Сформированный системой итоговый фильтр:
<syntaxhighlight lang="JavaScript">
[ "or", [ "in", [ "const", "all" ], [ "$USER", "SUBORDINATES" ] ], [ "in", [ "property", "worker_id" ], [ "$USER", "SUBORDINATES" ] ] ]
</syntaxhighlight>


[ "or", [ "in", [ "const", "all" ], [ "$USER", "SUBORDINATES" ] ], [ "in", [ "property", "worker_id" ], [ "$USER", "SUBORDINATES" ] ] ]
== Пример класса с настроенными ролями ==
В данном примере представлен код, описывающий класс и его поля, с настроенной фильтрацией по ролям. Массив dataProperties является [[Хранение данных. Классы. Поля и действия|коллекцией полей data]] класса.


= Типовой пример класса. =
Основные правила безопасности (под гостями, пользователями и администраторами здесь подразумеваются обладатели ролей zoo_guest, zoo_user и zoo_admin; напомним, что обладатели роли admin всегда имеют полный неограниченный доступ ко всем классам):  
Основные правила безопасности (под гостями, пользователями и администраторами здесь подразумеваются обладатели ролей zoo_guest, zoo_user и zoo_admin; напомним, что обладатели роли admin всегда имеют полный неограниченный доступ ко всем классам):  


Строка 103: Строка 165:
* поле Стоимость видят администраторы и пользователи, изменяют только для "своих" строк;  
* поле Стоимость видят администраторы и пользователи, изменяют только для "своих" строк;  
* поле Примечания можно изменить только для незавершенных строк.
* поле Примечания можно изменить только для незавершенных строк.
 
<syntaxhighlight lang="javascript" line="1">
{ readRoles: ["zoo_guest"], writeRoles: ["zoo_admin", "zoo_user"], readFilter: { roles: ["zoo_admin"], userPropertyNames: ["author_id", "worker_id"], }, writeFilter: { roles: ["zoo_admin", "zoo_user"], userPropertyNames: ["author_id"], }, dataProperties: [ { name: "finished", caption: "Завершена", dataType_fullName: "base/Boolean", }, { name: "author_id", caption: "Автор", dataType_fullName: "base/Uuid", defaultValue: "DataFactory.sessionInfo.userid", optionsUI: { editor_fullName: "root/iam/RootUser", readOnly: true } }, { name: "worker_id", caption: "Исполнитель", dataType_fullName: "base/Uuid", optionsUI: { editor_fullName: "root/iam/RootUser" } }, { name: "price", caption: "Цена", dataType_fullName: "base/Integer", readFilter: { roles: ["zoo_admin", "zoo_user"], }, writeFilter: { roles: ["zoo_admin"], }, }, { name: "cost", caption: "Стоимость", dataType_fullName: "base/Integer", readFilter: { roles: ["zoo_admin", "zoo_user"], }, writeFilter: { userPropertyNames: ["author_id"], }, }, { name: "notes", caption: "Примечания", dataType_fullName: "base/String", writeFilter: { customFilter: ["==", ["property", "finished"], ["const", false]] }, }, ]
{
 
    readRoles: ["zoo_guest"],
    writeRoles: ["zoo_admin", "zoo_user"],
    readFilter: {
        roles: ["zoo_admin"],
        userPropertyNames: ["author_id", "worker_id"],
    },
    writeFilter: {
        roles: ["zoo_admin", "zoo_user"],
        userPropertyNames: ["author_id"],
    },
    dataProperties: [{
        name: "finished",
        caption: "Завершена",
        dataType_fullName: "base/Boolean",
    }, {
        name: "author_id",
        caption: "Автор",
        dataType_fullName: "base/Uuid",
        defaultValue: "DataFactory.sessionInfo.userid",
        optionsUI: {
            editor_fullName: "root/iam/RootUser",
            readOnly: true
        }
    }, {
        name: "worker_id",
        caption: "Исполнитель",
        dataType_fullName: "base/Uuid",
        optionsUI: {
            editor_fullName: "root/iam/RootUser"
        }
    }, {
        name: "price",
        caption: "Цена",
        dataType_fullName: "base/Integer",
        readFilter: {
            roles: ["zoo_admin", "zoo_user"],
        },
        writeFilter: {
            roles: ["zoo_admin"],
        },
    }, {
        name: "cost",
        caption: "Стоимость",
        dataType_fullName: "base/Integer",
        readFilter: {
            roles: ["zoo_admin", "zoo_user"],
        },
        writeFilter: {
            userPropertyNames: ["author_id"],
        },
    }, {
        name: "notes",
        caption: "Примечания",
        dataType_fullName: "base/String",
        writeFilter: {
            customFilter: ["==", ["property", "finished"],
                ["const", false]
            ]
        },
    }, ]
}
</syntaxhighlight>
  Следующая статья курса: [[Задание 3. Настройка ролей]]
  Следующая статья курса: [[Задание 3. Настройка ролей]]


  Предыдущая статья курса: [[Задание 2. Настройка приложения]]
  Предыдущая статья курса: [[Задание 2. Настройка приложения]]
[[Категория:Курс "Разработка приложений"]]
[[Категория:Курс "Разработка приложений"]]

Текущая версия от 01:09, 20 января 2025

Предыдущая статья курса: Задание 2. Настройка приложения

Общая информация

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

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

Создаваемая роль может быть унаследована от существующей роли. В таком случае, права родительской роли будут распространяться и на дочернюю, но не наоборот.

Параметры роли
Имя Описание
package Пакет, в котором содержится элемент
name Наименование роли
fullName Полное имя (пакет и наименование)
parentRoles Родительские роли (их маршруты будут унаследованы)
routes Маршруты – права доступа к узлам дерева API (JSON)

Использование ролей в настройках приложения

Доступ к приложению, или отдельным его контролам может быть ограничен с помощью ролей.

В параметрах приложения и элемента Toolbox, можно заполнить массив roles. В таком случае, данное приложение, или элементы Toolbox будут видны только указанным ролям. Данная настройка влияет только на отображение, она не ограничивает доступ пользователей к данным любым другим способом (например, через API, или через присоединенные классы в других контролах).

Если массив ролей пустой, то такое приложение (или элемент Toolbox) будет доступно всем пользователям системы.

Использование ролей в настройках класса

В системе классов присутствует гибкий механизм настройки прав доступа.

Реализуется три уровня ограничения:

  • Ограничение доступа к данным класса целиком (readRoles, writeRoles, readByIDRoles)
  • Ограничение доступа к конкретным записям (объектам) класса (readFilter, writeFilter)
  • Ограничение доступа к конкретным свойствам (полям) класса (readFilter и writeFilter в коллекции свойств data)

Настройки ограничения доступа к данным класса и к конкретным записям, находятся в редакторе класса, на вкладке Security.

Настройки ограничения доступа к свойствам (полям) класса, находятся в редакторе элементов коллекции свойств data.

Разберем все три уровня ограничений и доступные для них настройки.

Ограничение доступа к данным класса целиком

Настройки доступа к данным класса

Общее ограничение доступа к данным класса реализуется тремя параметрами:

  • readRoles - роли, которым разрешено чтение
  • writeRoles - роли, которым разрешена запись (Insert, Update)
  • readByIDRoles - роли, которым запрещено общее чтение, но разрешено чтение конкретных записей по идентификатору (например, для присоединенных классов)

Если у класса все списки пусты – все роли пакета имеют разрешение на чтение и запись. Если задан только список ролей для записи, все роли пакета получают доступ на чтение, а перечисленные в списке роли - на чтение и запись. Если задан только список ролей для чтения, никто не получит прав на запись.

Ограничение доступа к конкретным записям класса

Блог параметров readFilter

Для ограничения доступа к конкретным записям используются блоки параметров readFilter (для ограничений доступа на чтение) и writeFilter (для ограничений доступа на запись) в редакторе класса. По принципу работы и настройки эти блоки идентичны, поэтому рассмотрим пример их настройки на базе readFilter.

Настройки фильтра определяются четырьмя основными параметрами, а также могут быть определны произвольным JSON:

  • roles - список ролей, которым доступны все записи класса, т.е. фильтр будет игнорироваться
  • userPropertyNames - список полей с типом root/iam/RootUser, по которым будет определяться принадлежность записи к конкретному пользователю. В случае настройки этого фильтра, каждый пользователь будет видеть только "свои" записи
  • subordinatedPropertyNames - список полей с типом root/iam/RootUser, по которым будет определяться принадлежность записи к подчиненным текущего пользователя. В случае настройки этого фильтра, каждый пользователь будет видеть только записи "своих подчиненных"
  • mandatePropertyName - имя поля, содержащего информацию о необходимом мандате доступа. Простыми словами - уровень доступа пользователя, требуемый для работы с этими данными. Уровень доступа пользователя определяется значением поля security.mandate в учетной записи пользователя, всех его групп и ролей.
  • customFilter - JSON, описывающий произвольный механизм фильтрации

Готовый фильтр после формирования сохраняется в параметр result. Его можно использовать для изучения и дальнейшего составления собственного фильтра для customFilter.

Ограничение доступа к конкретным свойствам класса

Вкладка Security

Для ограничения доступа к конкретным свойствам (полям) используется аналогичный механизм readFilter/writeFilter, но уже в коллекции свойств data, на вкладке Security.

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

Примеры организации ограничения доступа

Ролевой доступ к классу

Пример в редакторе класса

Для класса можно указать список ролей, для которых класс доступен на чтение и запись (свойства readRoles и writeRoles на вкладке Security). Разрешение записи приводит к автоматическому разрешению чтения. Если оба списка пусты, все роли пакета получают полный доступ к классу.

Если задан только список ролей для записи, все роли пакета получают доступ на чтение, а перечисленные в списке роли - на чтение и запись. Если задан только список ролей для чтения, никто не получит прав на запись.

Пример класса, который доступен на чтение ролям zoo_admin, zoo_user и zoo_guest, а на запись - только zoo_admin и zoo_user:

readRoles: ["zoo_guest"]
writeRoles: ["zoo_admin", "zoo_user"]

Ролевой доступ к классам приводит к формированию списка routes для каждой роли в процессе активации пакета. Поэтому поля readRoles и writeRoles могут содержать только роли текущего пакета. Для обеспечения доступа к классам других пакетов нужно задавать необходимые routes для соответствующих ролей

Ограничение доступа к строкам (объектам) класса

Пример в редакторе класса

Обеспечивается условиями фильтра для чтения и записи (группы readFilter и writeFilter на вкладке Security) с поддержкой специальной функции $USER. Реализация наиболее распространенных кейсов (доступ по ролям, фильтрация "своих" строк по указанным полям, фильтрация строк подчиненных пользователей и простейшая мандатная правовая модель) сведена к перечислению ролей (свойство roles) и полей (свойства userPropertyNames, subordinatedPropertyNames, mandatePropertyName), остальные кейсы решаются явным указанием произвольного фильтра (свойство customFilter).

Пример класса, который полностью доступен на чтение роли zoo_admin, а остальным ролям - только выборка "своих" строк по одному из полей author_id или worker_id:

readFilter: { roles: ["zoo_admin"], userPropertyNames: ["author_id", "worker_id"], }

Итоговый фильтр формируется системой автоматически (логическим оператором or) и доступен для контроля на карточке класса:

[ "or", [ "in", "zoo_admin", [ "$USER", "ROLES" ] ], [ "or", [ "==", [ "property", "author_id" ], [ "$USER", "id" ] ], [ "==", [ "property", "worker_id" ], [ "$USER", "id" ] ] ] ]

Полный перечень доступных функций приведен в документации на портале vendor. Предусмотрен доступ к свойствам учетной записи пользователя, его группам и ролям, подчиненным пользователям, а также агрегация произвольного поля security для поиска необходимого значения мандата

Ограничение доступа к столбцам (полям) класса

Пример в редакторе свойства класса

Пример поля, которое доступно для чтения и записи только конкретным ролям:

readFilter: { roles: ["zoo_admin", "zoo_user"], },
writeFilter: { roles: ["zoo_admin"], }

Пример поля, которое доступно для записи только для "своих" (по полю author_id) строк:

writeFilter: { userPropertyNames: ["author_id"], }

Пример поля, которое доступно для записи только для незавершенных (по полю finished) задач:

writeFilter: { customFilter: ["==", ["property", "finished"], ["const", false]] }

Условия visibility и readOnly для полей на элементах управления (в частности, в таблицах и карточках) необходимо задавать отдельно. Вполне вероятно, что в последующих версиях условия фильтрации полей будут приводить к их автоматическому скрытию или переводу в режим readOnly.

Мандатная правовая модель

В некоторых случаях бывает удобно от ролевой модели безопасности перейти к мандатной. Для этого в свойствах пользователей, групп и ролей предназначено поле security, которое может иметь произвольную структуру (например, security: { "mandate": 5 }). Для обращения к мандату пользователя в фильтре необходимо использовать конструкцию вида ["$USER", "security", "mandate"], а для поиска минимального либо максимального значения мандата с учетом пользователя, всех его групп и ролей - ["$USER", "DEEP", "MIN", "security", "mandate"] либо ["$USER", "DEEP", "MAX", "security", "mandate"]. Таким образом, если одно из полей класса содержит числовое значение необходимого мандата доступа, в условиях фильтров (как для строк, так и для столбцов) можно выполнить необходимую проверку (как правило - значение мандата пользователя должно быть не менее, чем значение мандата объекта).

Пользователю доступны строки, значение поля accessLevel которых меньше или равно максимальному значению security.accessLevel пользователя, его групп и ролей:

 readFilter: { mandatePropertyName: "accessLevel" }

Сформированный системой итоговый фильтр:

 [ ">=", [ "$USER", "DEEP", "MAX", "security", "accessLevel" ], [ "property", "accessLevel" ] ]

Богатая функциональность и гибкость механизма фильтров (описанная в предыдущих разделах) позволяет строить достаточно сложные схемы разграничения прав доступа на пересечении четырех размерностей: чтение-запись, классы, строки, столбцы.

Подчиненность пользователей

Для отображения пользователю строк, поле worker_id которых содержит идентификатор любого подчиненного ему пользователя (либо ему подчинены все), необходимо задать следующий фильтр:

 readFilter: { subordinatedPropertyNames: ["worker_id"], }

Сформированный системой итоговый фильтр:

 [ "or", [ "in", [ "const", "all" ], [ "$USER", "SUBORDINATES" ] ], [ "in", [ "property", "worker_id" ], [ "$USER", "SUBORDINATES" ] ] ]

Пример класса с настроенными ролями

В данном примере представлен код, описывающий класс и его поля, с настроенной фильтрацией по ролям. Массив dataProperties является коллекцией полей data класса.

Основные правила безопасности (под гостями, пользователями и администраторами здесь подразумеваются обладатели ролей zoo_guest, zoo_user и zoo_admin; напомним, что обладатели роли admin всегда имеют полный неограниченный доступ ко всем классам):

  • доступен гостям для чтения, а пользователям и администраторам для записи;
  • администраторы читают все строки, остальные роли - только "свои" по двум полям;
  • администраторы и пользователи изменяют все строки, остальные - только "свои" по одному полю;
  • поле Цена видят администраторы и пользователи, изменяют только администраторы;
  • поле Стоимость видят администраторы и пользователи, изменяют только для "своих" строк;
  • поле Примечания можно изменить только для незавершенных строк.
 {
    readRoles: ["zoo_guest"],
    writeRoles: ["zoo_admin", "zoo_user"],
    readFilter: {
        roles: ["zoo_admin"],
        userPropertyNames: ["author_id", "worker_id"],
    },
    writeFilter: {
        roles: ["zoo_admin", "zoo_user"],
        userPropertyNames: ["author_id"],
    },
    dataProperties: [{
        name: "finished",
        caption: "Завершена",
        dataType_fullName: "base/Boolean",
    }, {
        name: "author_id",
        caption: "Автор",
        dataType_fullName: "base/Uuid",
        defaultValue: "DataFactory.sessionInfo.userid",
        optionsUI: {
            editor_fullName: "root/iam/RootUser",
            readOnly: true
        }
    }, {
        name: "worker_id",
        caption: "Исполнитель",
        dataType_fullName: "base/Uuid",
        optionsUI: {
            editor_fullName: "root/iam/RootUser"
        }
    }, {
        name: "price",
        caption: "Цена",
        dataType_fullName: "base/Integer",
        readFilter: {
            roles: ["zoo_admin", "zoo_user"],
        },
        writeFilter: {
            roles: ["zoo_admin"],
        },
    }, {
        name: "cost",
        caption: "Стоимость",
        dataType_fullName: "base/Integer",
        readFilter: {
            roles: ["zoo_admin", "zoo_user"],
        },
        writeFilter: {
            userPropertyNames: ["author_id"],
        },
    }, {
        name: "notes",
        caption: "Примечания",
        dataType_fullName: "base/String",
        writeFilter: {
            customFilter: ["==", ["property", "finished"],
                ["const", false]
            ]
        },
    }, ]
}
Следующая статья курса: Задание 3. Настройка ролей
Предыдущая статья курса: Задание 2. Настройка приложения