AZykov (обсуждение | вклад) Нет описания правки |
AZykov (обсуждение | вклад) |
||
Строка 28: | Строка 28: | ||
|Маршруты – права доступа к узлам дерева API (JSON) | |Маршруты – права доступа к узлам дерева API (JSON) | ||
|} | |} | ||
= Использование ролей в настройках приложения = | |||
Доступ к приложению, или отдельным его контролам может быть ограничен с помощью ролей. | |||
В параметрах приложения и элемента Toolbox, можно заполнить массив roles. В таком случае, данное приложение, или элементы Toolbox будут '''видны''' только указанным ролям. Данная настройка влияет только на отображение, она не ограничивает доступ пользователей к данным любым другим способом (например, через API, или через присоединенные классы в других контролах). | |||
Если массив ролей пустой, то такое приложение (или элемент Toolbox) будет доступно всем пользователям системы. | |||
= Использование ролей в настройках класса = | = Использование ролей в настройках класса = | ||
В системе классов присутствует гибкий механизм настройки прав доступа. | |||
Реализуется три уровня ограничения: | |||
* Ограничение доступа к данным класса целиком (readRoles, writeRoles, readByIDRoles) | |||
* Ограничение доступа к конкретным записям (объектам) класса (readFilter, writeFilter) | |||
* Ограничение доступа к конкретным свойствам (полям) класса (readFilter и writeFilter в коллекции свойств data) | |||
Настройки ограничения доступа к данным класса и к конкретным записям, находятся в редакторе класса, на вкладке [[Хранение данных. Классы|Security]]. | |||
Настройки ограничения доступа к свойствам (полям) класса, находятся в [[Хранение данных. Классы. Поля и действия|редакторе элементов коллекции свойств data]]. | |||
Разберем все три уровня ограничений и доступные для них настройки. | |||
== Ограничение доступа к данным класса целиком == | |||
= Примеры организации ограничения доступа = | |||
== Ролевой доступ к классу | == Ролевой доступ к классу == | ||
Для класса можно указать список ролей, для которых класс доступен на чтение и запись (свойства readRoles и writeRoles на вкладке Security). Разрешение записи приводит к автоматическому разрешению чтения. Если оба списка пусты, все роли пакета получают полный доступ к классу. Если задан только список ролей для записи, все роли пакета получают доступ на чтение, а перечисленные в списке роли - на чтение и запись. Если задан только список ролей для чтения, никто не получит прав на запись. | Для класса можно указать список ролей, для которых класс доступен на чтение и запись (свойства readRoles и writeRoles на вкладке Security). Разрешение записи приводит к автоматическому разрешению чтения. Если оба списка пусты, все роли пакета получают полный доступ к классу. Если задан только список ролей для записи, все роли пакета получают доступ на чтение, а перечисленные в списке роли - на чтение и запись. Если задан только список ролей для чтения, никто не получит прав на запись. | ||
Строка 43: | Строка 68: | ||
Ролевой доступ к классам приводит к формированию списка routes для каждой роли в процессе активации пакета. Поэтому поля readRoles и writeRoles могут содержать только роли текущего пакета. Для обеспечения доступа к классам других пакетов нужно задавать необходимые routes для соответствующих ролей | Ролевой доступ к классам приводит к формированию списка routes для каждой роли в процессе активации пакета. Поэтому поля readRoles и writeRoles могут содержать только роли текущего пакета. Для обеспечения доступа к классам других пакетов нужно задавать необходимые routes для соответствующих ролей | ||
== Ограничение доступа к строкам (объектам) класса | == Ограничение доступа к строкам (объектам) класса == | ||
Обеспечивается условиями фильтра для чтения и записи (группы readFilter и writeFilter на вкладке Security) с поддержкой специальной функции $USER. Реализация наиболее распространенных кейсов (доступ по ролям, фильтрация "своих" строк по указанным полям, фильтрация строк подчиненных пользователей и простейшая мандатная правовая модель) сведена к перечислению ролей (свойство roles) и полей (свойства userPropertyNames, subordinatedPropertyNames, mandatePropertyName), остальные кейсы решаются явным указанием произвольного фильтра (свойство customFilter). | Обеспечивается условиями фильтра для чтения и записи (группы readFilter и writeFilter на вкладке Security) с поддержкой специальной функции $USER. Реализация наиболее распространенных кейсов (доступ по ролям, фильтрация "своих" строк по указанным полям, фильтрация строк подчиненных пользователей и простейшая мандатная правовая модель) сведена к перечислению ролей (свойство roles) и полей (свойства userPropertyNames, subordinatedPropertyNames, mandatePropertyName), остальные кейсы решаются явным указанием произвольного фильтра (свойство customFilter). | ||
Строка 57: | Строка 82: | ||
Полный перечень доступных функций приведен в [https://vendor.era-platform.ru/docs/era/latest/api/rest/v1/model/overview/index.html#read_collection_filter документации на портале vendor]. Предусмотрен доступ к свойствам учетной записи пользователя, его группам и ролям, подчиненным пользователям, а также агрегация произвольного поля security для поиска необходимого значения мандата | Полный перечень доступных функций приведен в [https://vendor.era-platform.ru/docs/era/latest/api/rest/v1/model/overview/index.html#read_collection_filter документации на портале vendor]. Предусмотрен доступ к свойствам учетной записи пользователя, его группам и ролям, подчиненным пользователям, а также агрегация произвольного поля security для поиска необходимого значения мандата | ||
== Ограничение доступа к столбцам (полям) класса | == Ограничение доступа к столбцам (полям) класса == | ||
Если для поля класса заданы фильтры чтения и записи (формат аналогичен фильтрам для строк), то при чтении будет выполняться автоматическая маскировка (скрытие) недоступных полей, а при записи недоступные поля будут игнорироваться. | Если для поля класса заданы фильтры чтения и записи (формат аналогичен фильтрам для строк), то при чтении будет выполняться автоматическая маскировка (скрытие) недоступных полей, а при записи недоступные поля будут игнорироваться. | ||
Строка 80: | Строка 105: | ||
Условия 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"]. Таким образом, если одно из полей класса содержит числовое значение необходимого мандата доступа, в условиях фильтров (как для строк, так и для столбцов) можно выполнить необходимую проверку (как правило - значение мандата пользователя должно быть не менее, чем значение мандата объекта). | ||
Строка 93: | Строка 118: | ||
Богатая функциональность и гибкость механизма фильтров (описанная в предыдущих разделах) позволяет строить достаточно сложные схемы разграничения прав доступа на пересечении четырех размерностей: чтение-запись, классы, строки, столбцы. | Богатая функциональность и гибкость механизма фильтров (описанная в предыдущих разделах) позволяет строить достаточно сложные схемы разграничения прав доступа на пересечении четырех размерностей: чтение-запись, классы, строки, столбцы. | ||
== Подчиненность пользователей | == Подчиненность пользователей == | ||
Для отображения пользователю строк, поле worker_id которых содержит идентификатор любого подчиненного ему пользователя (либо ему подчинены все), необходимо задать следующий фильтр: | Для отображения пользователю строк, поле worker_id которых содержит идентификатор любого подчиненного ему пользователя (либо ему подчинены все), необходимо задать следующий фильтр: | ||
<syntaxhighlight lang="JavaScript"> | <syntaxhighlight lang="JavaScript"> |
Версия от 00:38, 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 на вкладке 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. Настройка приложения