Интеграция QR-кодов Parsec с чат-ботом MAX

Введение

QR-код как идентификатор доступа — один из самых удобных способов выдать пропуск без физической карты. Сотрудник или посетитель получает код на смартфон, подносит экран к считывателю и проходит через турникет или дверь. В экосистеме Parsec этот сценарий реализуется через технологию защищенных QR-кодов формата Parsec, где считыватель PNR-QX29 анализирует прочитанный код и передает данные в контроллер доступа.

Примечание
QR Parsec (существует два вида: простой и расширенный) — это технология, а не готовое решение под ключ. Parsec предоставляет криптографию, форматы данных, средства генерации и консультации по интеграционному сервису. А канал доставки пропуска пользователю (чат-бот, почта, мобильное приложение, личный кабинет на сайте) проектируется и реализуется силами интегратора или заказчика под собственную IT-инфраструктуру.

Статья раскрывает, где и как применять эту технологию в разных типах проектов, чем отличаются простой и расширенный форматы, какие есть способы генерации кодов и как выглядит типовой сценарий интеграции с мессенджером MAX через чат-бот, как пример того, что строит интегратор поверх технологии Parsec.

QR Parsec. Технология на базе готовой инфраструктуры СКУД

Parsec не поставляет готовый чат-бот, мобильное приложение или портал самообслуживания для выдачи QR. Это осознанная архитектурная модель: технология остается гибкой, а заказчик сам выбирает любой канал, который соответствует его процессам (корпоративный MAX, email для гостей, мобильное приложение для сотрудников или веб-кабинет для подрядчиков).

Два типа QR Parsec в ParsecNET3

Простой QR Parsec

Зашифрованный QR с идентификатором доступа внутри (аналог обычной proximity-карты, длина кода до 7 байт). Считыватель расшифровывает код, извлекает ID и передает его в контроллер. Дальше работает стандартная логика СКУД: код сверяется с внутренней базой контроллера аналогично работе с обычной картой.

Расширенный QR Parsec

Зашифрованный QR со структурированным набором полей:

• ID групп контроллеров доступа (то, куда разрешен доступ);
• код идентификатора длиной до 4 байт (может быть не привязан к субъекту в СКУД; если код совпадает с существующим в системе, Parsec подставит субъекта в событие прохода);
• дата и время начала и окончания действия доступа (используются для короткого срока действия, например, несколько минут);
• время начала и окончания интервала доступа в дни, не попадающие на начало и конец периода (дневное окно для промежуточных дней многодневного периода).

Параметры срока задаются в формате ISO 8601 (как в интеграционной библиотеке libqr и документации на расширенный QR). 

Главное преимущество: возможность регулярного перевыпуска QR с заданным интервалом и ограниченным сроком действия без потери данных о субъекте доступа в СКУД. Это снижает риск клонирования и передачи QR третьим лицам.

Ограничения ParsecNext

В ParsecNext на текущий момент реализован только простой QR Parsec. Расширенный формат и штатный перевыпуск QR с коротким сроком действия не поддерживаются.

Практический вывод: При проектировании на ParsecNext интегратор работает с REST API платформы. Это принципиально иной интерфейс по сравнению с SOAP-сервисом ParsecNET3. Сценарий «живого» QR с коротким TTL на ParsecNext потребует пересмотра архитектуры или гибридного решения на переходный период.

Требования к оборудованию

Для простого QR:

• Считыватель: PNR-QX29 (обязательно).
• Контроллер: Любой поддерживаемый контроллер Parsec.

Для расширенного QR (только ParsecNET3):

• Считыватель: PNR-QX29 (обязательно).
• Контроллер: NC-100K-IP.M (для связи со считывателем рекомендуется интерфейс OSDP).
• Обратите внимание: Именно эти контроллеры работают со структурой расширенного QR Parsec. Связка PNR-QX29 + NC-8000 для расширенного формата не подойдет.

Способы генерации QR-кодов

Оба типа QR в ParsecNET3 можно получить двумя путями. Интегратор выбирает способ и встраивает его в свою инфраструктуру доставки.

1. Интеграционный сервис ParsecNET3 (SOAP)
   Внешнее приложение отправляет SOAP-запрос на сервер интеграции СКУД и получает готовое значение QR для визуализации. Parsec консультирует по работе с этим сервисом, а клиентская часть реализуется на стороне интегратора.
   Подходит для: централизованной архитектуры с постоянной связью с сервером ParsecNET3, единой точки контроля и умеренной нагрузки.
2. Интеграционная библиотека Parsec libqr
   Библиотека встраивается во внешнее приложение интегратора и генерирует QR локально, без синхронного SOAP-запроса при каждом обращении.
   Подходит для: высокой оперативности выпуска, автономных или распределенных сценариев, ботов и мобильных приложений с большим числом одновременных пользователей.
3. ParsecNext REST API
   Взаимодействие со СКУД осуществляется через REST API платформы. Генерация QR-значения происходит через штатные механизмы ParsecNext или libqr, в зависимости от согласованной архитектуры.

Сравнение подходов

Применимость в разных типах проектов

Во всех сценариях Parsec обеспечивает технологию QR и СКУД, а канал доставки остается в зоне ответственности интегратора или заказчика.

Рекомендации для проектов с миграцией на ParsecNext:

• Закладывать только простой QR;
• Проектировать интеграцию на REST API, а не переносить SOAP-клиент как есть;
• Не строить критичные процессы на расширенном формате.

Примерный сценарий интеграции: выдача QR через бота MAX

Ниже представлен пример типовой архитектуры, которую интегратор или заказчик реализует поверх технологии QR Parsec и СКУД ParsecNET3. MAX-бот — лишь один из возможных каналов доставки. Аналогичная схема применима для email, мобильного приложения или веб-кабинета.

Исходные условия (обязательные для сценария):

1. Бот MAX: Зарегистрирован в платформе, получен access_token. Для продуктовой среды настроена подписка на события (POST /subscriptions) на HTTPS-адрес сервера интегратора (порт 443, доверенный TLS). Базовый URL API: platform-api2.max.ru. Токен передается в заголовке Authorization.
2. Сервер интегратора: Принимает события бота, реализует бизнес-логику выдачи QR, аудит и обращение к СКУД или libqr. Длительный опрос событий (Long Polling) не рекомендуется.
3. СКУД Parsec: В карточке субъекта заранее создано дополнительное поле (например, «Телефон») и заполнено номером. По этому полю сервер интегратора проверяет наличие субъекта и право выдать QR.
4. Для проверки и данных о пропуске сервер интегратора обращается к интеграционному сервису Parsec (ParsecNET3, SOAP): ищет субъекта по дополнительному полю «Телефон», убеждается, что доступ разрешён, получает код идентификатора.
5. Сервер интегратора формирует QR-код Parsec: либо запрашивает готовую строку у интеграционного сервиса (вариант А), либо генерирует её локально библиотекой libqr (вариант Б). Затем собирает из строки картинку QR.
6. Картинка QR возвращается пользователю в чат бота MAX (через API MAX) вместе с короткой подсказкой: поднести экран к считывателю, при необходимости: до какого времени действует пропуск.
7. Пользователь подходит к точке прохода и предъявляет QR на экране телефона считывателю PNR-QX29.
8. Считыватель расшифровывает код и передаёт данные в контроллер доступа. Контроллер принимает решение о доступе (для простого QR: по базе идентификаторов; для расширенного: ещё и по сроку и зоне, зашитым в QR).
9. При разрешении контроллер управляет исполнительной периферией: открывается дверь или турникет, пользователь проходит. Факт прохода фиксируется в СКУД. Если на шагах 3-5 проверка не пройдена (номер не найден, доступ запрещён, сработала политика ИБ), бот сообщает об отказе простым текстом и QR не выдаёт.

Рисунок. Архитектура выдачи QR Parsec через бота MAX.

Пользовательский сценарий (шаг за шагом)

Технические детали скрыты на стороне интегратора, пользователь их не видит:

1. Пользователь открывает мессенджер MAX и находит бота пропуска.
2. В чате с ботом нажимает кнопку авторизации (например, «Поделиться контактом»). MAX отправляет боту номер, привязанный к аккаунту.
3. Бот передает номер на сервер интегратора, который сверяет телефон с данными в СКУД и применяет правила службы информационной безопасности (ИБ).
4. Сервер интегратора обращается к SOAP-сервису Parsec, ищет субъекта по полю «Телефон», проверяет доступ и получает код идентификатора.
5. Сервер интегратора формирует QR-код (запрашивает строку у сервиса Parsec или генерирует ее локально библиотекой libqr) и собирает картинку QR.
6. Картинка возвращается пользователю в чат MAX вместе с короткой подсказкой.
7. Пользователь предъявляет QR на экране телефона считывателю PNR-QX29.
8. Считыватель расшифровывает код и передает данные в контроллер, который принимает решение о доступе.
9. Турникет или дверь открывается, а факт прохода фиксируется в СКУД.

(Если на шагах 3–5 проверка не пройдена, бот сообщает об отказе простым текстом без выдачи QR).

Многоуровневая проверка права выдать QR (зона ИБ заказчика)

Примерный сценарий реализации кода

Шаг 0. Подготовка бота и подписки на события

Шаг 1. Старт диалога и получение телефона

Шаг 2. Поиск субъекта в СКУД (псевдокод)

Шаг 3. Запрос пропуска пользователем.
Сотрудник нажимает кнопку/команду в боте («Получить QR»). Сервер интегратора повторно прогоняет цепочку проверок ИБ (на случай блокировки между регистрацией и запросом).

Шаг 4. Генерация QR через libqr (C-код)

(Ключ AES libqr должен совпадать с ключом считывателей PNR-QX29 объекта и храниться в надежном хранилище секретов).

Безопасность (зона интегратора)

Заключение

Итог для проектировщика: Parsec предоставляет технологию QR и данные СКУД, MAX выступает транспортом до пользователя, а сервер интегратора — это место, где сходятся телефон из MAX, дополнительное поле субъекта, политики ИБ и выбранный способ генерации.

При проектировании фиксируйте в техническом задании: платформу (ParsecNET3 или ParsecNext), тип QR, модели контроллеров, способ генерации, канал доставки и границы ответственности. Тогда интеграция будет предсказуемой, а ожидания заказчика совпадут с моделью «технология от Parsec, решение от интегратора».