Гранула security

Материал из Course Orchestra
Перейти к: навигация, поиск
Внимание! Вы просматриваете документацию к Celesta 6.x. Документация по Celesta 7.x доступна на courseorchestra.github.io/celesta.

1. Справочник Celesta

1.1 Введение и основные понятия
1.2 Запуск и авто-обновление
1.3 Базовая настройка
1.4 Системные таблицы
1.5 CelestaSQL
1.6 CelestaDoc
1.7 Контексты сессии и вызова
1.8 Курсоры
1.9 BLOB-поля
1.10 Option-поля
1.11 Защита от потерянных обновлений
1.12 Метаданные Celesta
1.13 CelestaUnit

2. Celesta и базы данных

2.1 Особенности работы Celesta с поддерживаемыми типами СУБД
2.2 Проектирование базы данных Celesta в DBSchema

3. Создание решений с использованием Celesta для ShowCase

3.1 Программа обучения Celesta
3.2 Подготовка рабочего места для работы с Celesta
3.2.1 Для разработчиков платформы
3.2.2 Для разработчиков решений
3.3 Системные гранулы Celesta
3.3.1 common
3.3.1.1 Экспорт/импорт данных
3.3.1.2 Навигатор
3.3.1.3 Серии номеров
3.3.1.4 Иерархия Дьюи
3.3.1.5 Системные функции
3.3.1.6 Реестр настроек
3.3.1.7 Mailsender
3.3.1.8 Common.filter
3.3.2 common.api
3.3.4 security
3.3.3 lyra
3.4 Стандартные гранулы Celesta
3.4.1 dirusing
3.4.2 workflow
3.4.3 File repository
3.5 Отрисовка элементов Showcase при помощи Celesta
3.5.1 Конвертер XML-JSON
3.5.2 Навигатор (Navigator)
3.5.3 Информационная панель (Datapanel)
3.5.4 Серверное действие (Server activity)
3.5.5 Вебтекст (WebText)
3.5.6 Грид (Grid)
3.5.6.1 Панель инструментов (ToolBar)
3.5.7 XForms
3.5.7.1 Селекторы
3.5.7.2 Submission
3.5.7.3 Загрузка/Выгрузка файлов (Upload/Download)

5. Решение проблем

5.1 Проблемы с кодировкой jython-файлов

Гранула security — это гранула, содержащая набор функций и классов, необходимых для ведения пользователей, сотрудников, ролей, разрешений на таблицы и прочих разрешений. Отвечает за:

  • отображение в навигаторе Showcase группы "Разграничение прав доступа";
  • ведение таблиц пользователей, сотрудников, ролей, разрешений на таблицы и прочих разрешений.

Необходимые гранулы для работы: common.

Подготовка к работе

В файле common/grainsSettings.xml должен содержаться тег grain следующего вида:

<grain name="security">
	<securitySettings>
		<parameter name="employeesGrain" value=""/>
		<parameter name="employeesTable" value=""/>
		<parameter name="employeesId" value=""/>
		<parameter name="employeesName" value=""/>
		<parameter name="isSystemInitialised" value="false"/>
		<parameter name="useAuthServer" value="false"/>
		<parameter name="loginEqualSubject" value="true"/>
	</securitySettings>			
</grain>

Подробнее о файле настройки: Общий реестр настроек гранул

  • Параметр useAuthServer отвечает за источник справочника пользователей. Если параметр принимает значение false, грид пользователей заполняется из таблицы logins гранулы security. В противном случае, грид заполняется списком пользователей, получаемым из Mellophone (бывший AuthServer).

Параметр useAuthServer должен принимать значение false в том и только в том случае, если sql провайдер Mellophone настроен на таблицу logins.

  • Параметр loginEqualSubject отвечает за то, к чему будут привязаны роли. Если параметр принимает значение false, роли привязываются к указываемой в настроечном файле common/grainSettings.xml таблице сотрудников. В противном случае, роли привязываются к пользователям, получаемым либо из таблицы logins, либо из Mellophone. Фактически этот параметр означает включение или отключения режима маппинга, т.е. сопоставления сотруднику одного либо нескольких пользователей(логинов).
  • employeesGrain - параметр, содержащий название гранулы, в которой содержится справочник сотрудников.
  • employeesTable - параметр, содержащий название таблицы, в которой содержится справочник сотрудников.
  • employeesId, employeesName - параметры, содержащие соответственно название ключевого поля и поля имени таблицы сотрудников. Необходимо для корректной работы селектора в грануле security, а также для создания внешнего ключа в таблице subjects.
  • isSystemInitialised - параметр при настройке системы должен устанавливаться в значение false. При первом запуске, система создаёт внешние ключи:
    • logins.subjectId — subjects.sid
    • subjects.employeesId — "employeesTable"."employeesId"

Триггеры добавляются в зависимости от настроек. Затем система меняет значение параметра isSystemInitialised на true и сохраняет полученный файл настроек.

Если инициализация гранулы проводиться на уже существующей базе, нужно убедиться, что в таблице celesta.roles есть роль editor, а в таблице celesta.userroles — привязка роли editor к суперпользователю super.

Структура и варианты настроек

Гранула security непосредственно состоит из следующих таблиц:

  • logins — содержит имя пользователя, пароль и поле subjectId — внешний ключ на таблицу subjects.
  • subjects — в зависимости от значения параметра настроек loginsEqualSubjects, эта таблица эквивалентна либо таблице logins (loginsEqualSubjects="true"), либо таблице сотрудников (loginsEqualSubjects="false"). Subjects представляет собой таблицу субъектов, носителей прав. Таким образом, на таблицу subjects назначаются роли. Первичный ключ таблицы subjects — sid пользователя. Также в таблице есть внешний ключ на таблицу сотрудников, employeesId. Поле name таблицы содержит имя носителя прав. То есть, либо userName таблицы logins при loginsEqualSubjects="true", либо employeesName из таблицы сотрудников при loginsEqualSubjects="false".
  • customPerms, customPermsTypes и rolesCustomPerms — произвольные разрешения (разрешения, за исключением разрешений на чтение, запись, редактирование, удаление записей таблиц), типы произвольных разрешений и связи произвольных разрешений с ролями соответственно.

Таблицы logins и указываемая в настройках таблица сотрудников не связаны между собой внешними ключами напрямую.

Также используются таблицы гранулы celesta: roles, userroles, permissions.

Схема БД гранулы security до инициализации гранулы:

Securitygrain.png

Группа навигатора, описываемая гранулой, состоит из трёх пунктов меню: "Сотрудники и пользователи", "Роли", "Разрешения". Отображение и логика пункта "Сотрудники и пользователи" зависит от параметров useAuthServer и loginEqualSubject. В зависимости от принимаемых ими значений мы имеем четыре случая. Какой конкретно случай применить, определяется разработчиком соответствующего решения в зависимости от логики распределения прав в архитектуре решения.

useAuthServer = true, loginEqualSubject = true

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

T-t.png

В этом случае в пункте "Сотрудники и пользователи" отображается один грид "Пользователи". Добавление в грид и удаление записей из грида невозможно. Доступны только кнопки "Редактировать", которая позволяет привязать сотрудника к имени пользователя. Для верной работы селектора сотрудников в карточке, необходимо корректно указать значение параметров "employeesGrain", "employeesTable", "employeesId", "employeesName" в настроечном файле. Кнопка "Добавить роли" служит для привязки ролей к имени пользователя.

useAuthServer = true, loginEqualSubject = false

Пользователи берутся из Mellophone, права привязываются к сотруднику:

T-f.png

В пункте "Сотрудники и пользователи" отображается два грида. "Пользователи", аналогично соответствующему гриду из п.1, за исключением того, что в данном случае не доступна кнопка "Добавить роли", а в карточке редактирования селектор выбирается из таблицы subjects; "Субъекты", в котором отображаются sid пользователя и имя из таблицы subjects, которое совпадает с именем из таблицы сотрудников, указываемом в параметре настроек epmloyeesName. В данном случае при инициализации системы на курсор сотрудников добавляются celesta-триггеры, которые создают, модифицируют и удаляют записи в таблицу subjects вместе с записями в таблице сотрудников. Если в настроечном файле указана таблица сотрудников, у грида "Субъекты" доступна только одна кнопка — "Добавить роли". Если не указывать в настроечном файле таблицу сотрудников, в гриде "Субъекты" появляются еще и стандартные кнопки "Добавить", "Редактировать", "Удалить", позволяя использовать таблицу subjects вместо таблицы сотрудников.

useAuthServer = false, loginEqualSubject = true

Пользователи берутся из таблицы logins, права привязываются к имени пользователя. Cлучай "useAuthServer": false используется только тогда, когда sql провайдер настроен на таблицу logins:

F-t.png

В пункте "Сотрудники и пользователи" отображается один грид - "Пользователи". Этот грид представляет собой таблицу logins. Здесь доступен весь обычный набор кнопок: "Добавить", "Редактировать", "Удалить" и "Добавить роли". При создании/редактировании/удалении записей таблицы logins автоматически аналогичные действия совершаются со связанной записью из таблицы subjects. Селектор в карточке добавления/редактирования выбирает записи из таблицы сотрудников.

useAuthServer = false, loginEqualSubject = false

Пользователи берутся из таблицы logins, права привязываются к сотруднику. Случай аналогичный случаю 2, за исключением того, что в гриде "Пользователи" доступны также кнопки "Добавить", "Удалить", так как отображение идёт из таблицы logins, а не из Mellophone.

F-f.png

Общее описание работы гранулы с использованием внешней таблицы employees

Cотрудник(строка в "employeesTable", где PK "employeesId") может иметь несколько идентификаторов безопасности - sid(соответственно несколько логинов), так как поле employeeId таблицы subjects может быть не уникально в пределах таблицы subjects, т.е. связь один ко многим.

К одному идентификатору безопасности(sid) могут быть привязаны несколько логинов (userName), за счет того, что PK в таблице logins это поле userName, т.е. поле subjectId, являющееся внешним ключом, может быть не уникально в пределах таблицы logins, т.е. связь один ко многим. Учитывая программную реализацию привязки прав именно к значению sid таблицы subjects, может возникнуть ситуация, когда один сотрудник будет иметь несколько логинов с одинаковым набором прав. Поэтому на уровне интерфейса сделано жесткое ограничение в виде связи один к одному - sid всегда соответствует одному логину. Сотрудник может иметь несколько логинов, т.е. несколько разных sid, соответственно несколько разных наборов прав.

Общее описание работы гранулы без использования внешней таблицы employees

Сотрудник(строка в subjects, где PK sid) может иметь несколько sid, так как поле name таблицы subjects может быть не уникально в пределах таблицы subjects.

Роли

В пункте «Роли» находятся грид «Роли» и зависимый от него грид «Разрешения» без возможности редактирования, показывающий, какие именно разрешения есть на данной роли. В гриде «Роли» кнопкой «Пользователи» можно назначить на конкретную роль пользователей. Roles.png

При создании либо модификации роли, автоматически добавляются разрешения на чтение таблиц:

  • celesta.userroles
  • celesta.permissions
  • celesta.roles
  • security.customPerms
  • security.rolesCustomPerms,
  • security.customPermsTypes

соответствующих данной роли. Это сделано для корректной работы проверки прав пользователей.

Разрешения

В пункте «Разрешения» ведётся список разрешений на добавление/редактирование/удаление записей в таблицах, а также прочие разрешения. Грид «Разрешения» можно отфильтровать по соответствующим полям. Для удобства ведения разрешений, данные фильтра передаются также в карточку разрешений, то есть, в карточке можно не выбирать каждый раз гранулу, роль и таблицу при заполнении множества разрешений.

Permissions.png

Во вкладке «Прочие разрешения» ведётся грид разрешений, отличающихся от разрешений доступа к таблицам.

CustomPermissions.png

Каждому разрешению назначаются роли.

RolesCustomPermissions.png

Действия с прочими разрешениями прописываются непосредственно в решении. Во вкладке «Типы разрешений» ведётся грид типов прочих разрешений.

CustomPermissionsTypes.png

Для удобства миграции данных между решениями в гриды «Роли», «Разрешения», «Прочие разрешения» и связанного с ним грида, «Типы разрешений» (таблицы roles, permissions, customPerms, rolesCustomPerms, customPermsTypes соответственно) добавлены кнопки "Скачать" и "Загрузить", использующие модуль экспорта/импорта данных. Данные можно выгрузить в XML-файл (кнопка Скачать), либо наоборот, загрузить данные из XML в соответствующую таблицу (кнопка Загрузить). Загружать в таблицу данные можно только xml-файла, выгруженного ранее из тождественной таблицы.

security API

Функции, импортируемые из security.functions, которые могут пригодиться при разработке решений.

  • id_generator(size=8, chars=string.ascii_uppercase + string.ascii_lowercase + string.digits)

Функция генерирует произвольную строчку заданной длины и из заданного набора символов. По умолчанию, длина результирующей строки 8, набор символов - цифры и английские буквы.

  • getUsersFromAuthServer(server, sessionId)

Функция получает адрес Mellophone и ID сессии и возвращает xml с пользователями.

  • submissionGenPass(context, main=None, add=None, filterinfo=None, session=None, data=None)

Функция для submission, генерирующая пароль с помощью вызова id_generator

  • getPermissionsOfTypeAndUser(context, sid, permissionType=None)

Функция возвращает курсор с разрешениями типа permissionType, которые есть у данного пользователя с сидом sid. Если permissionType принимает знчения None или 'tables', функция возвращает разрешения из таблицы permissions. В противном случае - соответствующие разрешения из customPerms. Если для данных параметров разрешений нет, возвращает None.

  • userHasPermission(context, sid, permission)

Если у пользователя с сидом sid есть роль editor, либо разрешение permission, возвращается True. В случае, если разрешения не существует, или у данного пользователя нет такого разрешения и нет роди editor, возвращается False.

Класс Settings

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

  • getSettingsJSON()

Метод возвращает json с содержимым тега настроек гранулы security в виде {"@name":"@value"}

  • isUseAuthServer()

Метод возвращает значение параметра useAuthServer настроечного файла (True/False)

  • loginIsSubject()

Метод возвращает значение параметра loginEqualSubject настроечного файла (True/False)

  • isEmployees()

Метод возвращает True, если в настроечном файле параметры employeesGrain, employeesTable, employeesName одновременно принимают значения отличные от null и пустой строки. В противном случае возвращает False

  • isSystemInitialised()

Метод возвращает значение параметра isSystemInitialised настроечного файла (True/False)

  • getEmployeesParam(param)

Возвращает значение параметра настроечного файла с именем param

  • setEmployeesParam(param, value)

Присваивает параметру param из настроечного json'а значение value, одновременно сохраняя значение в файл common/grainsSettings.xml