Инструкция для менеджера
1. Назначение системы
Система прокторинга предназначена для подтверждения результатов онлайн-экзаменов при прохождении испытаний в системах дистанционного обучения (СДО). Система позволяет:
- дистанционно сопровождать испытуемого на протяжении всего экзамена;
- верифицировать личность испытуемого;
- выявлять возможные нарушения во время экзамена и выставлять оценку доверия;
- записывать протокол сеанса, включая звук, видео с веб-камеры и рабочего стола;
- разрешать возможные спорные моменты уже после экзамена на основании протокола сеанса.
2. Технические требования
Особых технических требований к компьютеру администратора нет. Для работы необходим любой современный веб-браузер. Рекомендуется использовать Chrome 72+, Opera 59+, Яндекс.Браузер 19.3+, Edge 79+.
3. Вход в систему
Для входа в систему прокторинга необходимо в веб-браузере открыть адрес системы прокторинга и ввести свои логин и пароль (рисунок 1). Для доступа к интерфейсу администратора пользователю должны быть даны соответствующие права.
После входа на верхней панели интерфейса в меню расположены кнопки переключения языка, развертывание окна на весь экран, параметры профиля пользователя и кнопка выхода. Слева находится меню навигации. А в центральной части выбранный в меню раздел. Чтобы избежать проблем с отображением времени, убедитесь, что время и часовой пояс на компьютере выставлены верно.
В профиле пользователя можно изменить логин, пароль и язык интерфейса менеджера (рисунок 2).
В профиле пользователя можно изменить логин, пароль и язык интерфейса менеджера (рисунок 2).
4. Управление конфигурациями
4.1 Список конфигураций
Каждая конфигурация представляет собой изолированный экземпляр системы прокторинга со своими параметрами и лицензией. Список таких конфигураций представлен в виде таблицы (рисунок 3).
4.2 Добавление новой конфигурации
Добавить новую запись в список конфигураций можно двумя способами:
1.Через кнопку «Добавить» (+) в интерфейсе.
Добавление новой записи представляет собой внесение лицензионного ключа и параметров экземпляра системы в список конфигураций. Конфигурации различаются между собой по имени хоста, у одной конфигурации не может быть двух разных хостов и у разных конфигураций не может быть одинакового хоста.
В лицензионном ключе кодируются:
1.Через кнопку «Добавить» (+) в интерфейсе.
Добавление новой записи представляет собой внесение лицензионного ключа и параметров экземпляра системы в список конфигураций. Конфигурации различаются между собой по имени хоста, у одной конфигурации не может быть двух разных хостов и у разных конфигураций не может быть одинакового хоста.
В лицензионном ключе кодируются:
- имя хоста экземпляра системы;
- сроки действия лицензии;
- единица тарификации;
- объем в единицах тарификации.
2.Через импорт конфигурации из файла JSON.
JSON файл для импорта конфигурации должен содержать поле «key» и дополнительно может содержать поле «params» с параметрами экземпляра системы. Пример:
JSON файл для импорта конфигурации должен содержать поле «key» и дополнительно может содержать поле «params» с параметрами экземпляра системы. Пример:
{
"key": "eyJhbGciOiJS...",
"params": {
"webhooks": {
"jwt": {
"authorizer": "jwt",
"integrator": "generic",
"secretOrKey": "secret",
"profile": {
"username": "payload.username",
"role": "payload.role",
"nickname": "payload.nickname"
},
"register": {
"identifier": "payload.identifier",
"subject": "payload.subject",
"url": "payload.url",
"template": "payload.template"
}
}
}
}
}4.3 Параметры интеграции
Параметры интеграции определяют способ обмена данными между системой прокторинга и СДО. Эти параметры указываются в разделе «webhooks». Формат полей следующий «webhooks..*», где — название провайдера интеграции (произвольный текстовый идентификатор).
Описание параметров:
Описание параметров:
- webhooks..authorizer — стратегия авторизации, может иметь значения: jwt, lti, plain.
- webhooks..integrator — поставщик интеграции: generic, lti.
- webhooks..secretOrKey — секретный ключ для стратегии авторизации «jwt».
- webhooks..consumerKey — ключ клиента для стратегии авторизации «lti».
- webhooks..consumerSecret — секретный ключ для стратегии авторизации «lti».
- webhooks..callbackURL — страница переадресации после успешной авторизации (например, "/"), по умолчанию выставляется «Referer». Используется только при входе в систему по ссылке, игнорируется при работе через SDK.
- webhooks..headers. — пользовательские заголовки для исходящих запросов для поставщика интеграции «generic».
- webhooks..timeout — время ожидания ответа в секундах для поставщика интеграции «generic».
- webhooks..method — HTTP-метод запроса (GET, POST, PUT, DELETE) для поставщика интеграции «generic».
- webhooks..uri — адрес отправки запроса для поставщика интеграции «generic», например, «room.api».
- webhooks..body — маппинг полей для формирования тела исходящего запроса для поставщика интеграции «generic».
- webhooks..attach. — маппинг полей для формирования типа исходящего запроса «multipart/form-data» и включения в запрос вложенных файлов для поставщика интеграции «generic».
- webhooks..profile. — маппинг полей для заполнения профиля пользователя, которые определяют логику соотношения внутренних и внешних полей. Внешние поля доступны через объект «payload».
- webhooks..register. — маппинг полей для заполнения параметров сеанса, который происходит сразу после авторизации пользователя и использует данные, которые передаются вместе с данными пользователя (объект «payload»).
- webhooks..start. — параметры обработчика, который вызывается в момент запуска сеанса и используется для передачи данных о запуске по API в СДО.
- webhooks..pause. — параметры обработчика, который вызывается в момент отключения пользователя более чем на 2 минуты и используется для передачи данных об этом событии по API в СДО.
- webhooks..stop. — параметры обработчика, который вызывается в момент остановки сеанса и используется для передачи данных о завершении по API в СДО.
- webhooks..submit. — параметры обработчика, который вызывается при выставлении или изменении заключения по сеансу и используется для передачи результатов по API в СДО.
4.4 Параметры SDK
Параметры SDK определяют настройки клиентской части системы прокторинга. Эти параметры указываются в разделе «sdk».
Описание параметров:
Описание параметров:
- sdk..height — максимальная высота изображения в пикселях.
- sdk..width — максимальная ширина изображения в пикселях.
- sdk..frameRate — максимальная частота кадров видео.
- sdk..bitrate.audio — битрейт аудиопотока для видеосвязи в Кбит/с.
- sdk..bitrate.video — битрейт видеопотока для видеосвязи в Кбит/с.
- sdk..recorder.audioBitsPerSecond — битрейт аудиозаписи в бит/с.
- sdk..recorder.videoBitsPerSecond — битрейт видеозаписи в бит/с.
- sdk.css.
--background-color: #FFF
--foreground-color: #000
--primary-color: #1CA1C1
--secondary-color: #EBEDF0
--success-color: #27AE60
--warning-color: #FFC107
--danger-color: #FF5C4C
--info-color: #A8A8A8
--preview-size: 90px
--preview-offset-x: 10px
--preview-offset-y: calc(100vh - 100px)
--foreground-color: #000
--primary-color: #1CA1C1
--secondary-color: #EBEDF0
--success-color: #27AE60
--warning-color: #FFC107
--danger-color: #FF5C4C
--info-color: #A8A8A8
--preview-size: 90px
--preview-offset-x: 10px
--preview-offset-y: calc(100vh - 100px)
- sdk.iframe.allow (строка) — опция «allow» в режиме IFRAME.
- sdk.iframe.sandbox (строка) — опция «sandbox» в режиме IFRAME.
4.5 REST API
Обычно такой API не требуется, т.к. большинство сценариев можно реализовать с использованием «webhooks». Однако в некоторых случаях требуется прямой доступ к данным или возможность их менять, в таких случаях HTTP RESTful API для входящих запросов может быть полезен. Настройки этого API указываются в разделе «rest». Формат настроек следующий «rest..*», где «name» — название точки доступа к API (произвольный текстовый идентификатор). Формат URL входящего запроса «/api/rest/:name/:model/:path».
Описание параметров:
Описание параметров:
- rest..headers. — заголовки, которые должны содержаться во входящем, если заголовки не совпадают, то такой запрос отклоняется.
- rest..api. — содержит параметры маршрутизации запросов (любое название).
- rest..api..model — указывает какая модель данных (коллекция данных) используется в контексте запроса (такие как room, user, storage).
- rest..api..method — метод запроса: GET, POST, PUT, DELETE.
- rest..api..path — относительный путь запроса, например, «/:id». Тут можно указывать параметры, добавив двоеточие перед названием параметра.
- rest..api..request. — маппинг полей тела входящего запроса.
- rest..api..response. — маппинг полей тела ответа на входящий запрос.
- rest..api..filter — поисковое выражение (для методов GET, PUT, DELETE).
- rest..api..skip — пропуск заданного количества записей в начале выдаче (для метода GET).
- rest..api..limit — ограничение количества записей в выдаче (для метода GET).
- rest..api..sort — сортировка записей в выдаче (для метода GET).
- rest..api..count — подсчет количества найденных записей (для метода GET).
- rest..api..single — возвращать всегда только одну запись, а не массив (для метода GET).
- rest..api..select — возврат в выдаче не всех, а только указанных записей (для метода GET, PUT, DELETE).
- rest..api..populate — заполнение полей, которые являются ссылками на другие коллекции данных (для всех методов).
5. Задачи
В разделе «Задачи» (рисунок 5) можно следить за выполнением фоновых задач, таких как сбор статистики по использованию системы, очистка ненужных загруженных файлов, автоматическое завершение и очистка сессий. На самом деле это скорее системная информация и может пригодиться только в случае каких-то проблем на сервере или с интеграцией.
6. Статистика
В интерфейсе «Статистика» (рисунок 6) отображается число активных сеансов, онлайн пользователей, использование процессора и оперативной памяти на сервере с учетом всех конфигураций. Можно указать интервал дат и времени, за который требуется просмотреть статистику. В верхней части интерфейса отображены максимальные значения показателей, которые были зафиксированы за указанный промежуток времени. Если не указывать дату, то данные будут отображены за последний час и каждую минуту будет происходить обновление графиков.
7. Журнал
В интерфейсе «Журнал» (рисунок 7) ведется история изменений в данных системы прокторинга. Данная функция создана для обеспечения прозрачности и контроля за действиями пользователей в системе.
В журнал сохраняются изменения в моделях “config”, “user”, “room”, “draft”. Если изменение связано с конкретным пользователем (например, изменил параметры сеанса или авторизовался в системе), то указывается "actor" этого изменения. Если изменение не связано напрямую с пользователем, то "actor" не указывается (например, когда меняется статус сеанса).
Менеджер может просмотреть журнал для всех хостов, включая хост менеджера. Журнал можно экспортировать в CSV. А используя фильтр можно выбрать только интересующие изменения из всех.
Менеджер может просмотреть журнал для всех хостов, включая хост менеджера. Журнал можно экспортировать в CSV. А используя фильтр можно выбрать только интересующие изменения из всех.