NexTool Solutions

В GLPI 11 есть встроенный вебхук: при каждом создании, изменении или удалении заявки он уведомляет другую систему по HTTP, с подписью и повторными попытками. Мы протестировали его в нашем GLPI поддержки, и первая настройка ничего не доставила. Причины не было ни на одном экране: GLPI отклоняет любой URL с портом, например :8080 или стандартный для n8n :5678. Это руководство показывает, как настроить, что измерил тест, и три детали, которые блокируют интеграцию.

Нужно больше, чем исходящий вебхук, — условия, несколько шагов или приём данных извне? См. Automations и вебхуки в GLPI с NexTool.

Что делает встроенный вебхук (и чего не делает)

Вебхук GLPI 11 — исходящий: когда с элементом что-то происходит, GLPI формирует сообщение и отправляет его на URL. Это нужно, чтобы уведомить ERP, создать карточку в Teams, обновить дашборд или запустить процесс в n8n.

• События: создание, обновление и удаление.
• Элементы: те же, что в новом API GLPI 11, — заявки, проблемы, изменения, активы и пользователи.
• Сообщение: по умолчанию элемент в формате API (статус, инициатор, команда, организация, даты), редактируемый с помощью переменных.

Он ничего не принимает. Чтобы другая система создавала или изменяла заявки в GLPI, нужно использовать API.

Где настроить

В Настройки > Вебхуки > Добавить:

И на вкладках:

• Критерии: фильтрует, какие элементы вызывают отправку, по тем же критериям, что и поиск. Например, только заявки категории «Закупки».
• Редактор полезной нагрузки: заменяет стандартное сообщение вашим шаблоном, с предпросмотром.
• Безопасность: секрет подписи, проверочный вызов URL и аутентификация OAuth.
• Пользовательские заголовки: например, Authorization или Content-Type.

Тест: что мы измерили

Мы создали два вебхука в тестовой организации нашего GLPI поддержки (вымышленная компания Acme) и создали заявки. Один указывал на адрес, отвечающий 200; другой — на адрес, отвечающий ошибкой 500.

Три детали, которые блокируют интеграцию

1. URL с портом отклоняется

GLPI 11 вызывает только URL, прошедшие список разрешённых (защита от злоупотребления сервером). Правило по умолчанию принимает домен, IP и путь, но не принимает порт. Ошибка не появляется на экране: она записывается в webhook.log как «Webhook target URL ... is unsafe».

Мы проверили функцию самого GLPI:

Решение: публикуйте адресата на стандартном порту (443 или 80), обычно за обратным прокси. Это заодно решает вопрос HTTPS. Список можно расширить константой GLPI_SERVERSIDE_URL_ALLOWLIST, но она действует для всех обращений сервера к внешним URL, поэтому меняйте её осторожно.

2. Без Content-Type адресат может не понять JSON

GLPI отправляет тело в JSON, но без заголовка Content-Type. Такие инструменты, как n8n, и многие фреймворки читают тело как JSON, только если об этом говорит заголовок.

Решение: в «Пользовательских заголовках» добавьте Content-Type: application/json.

3. Без cron ничего не уходит

Вебхук не отправляется сразу: он попадает в очередь, а автоматическое действие queuedwebhook отправляет его каждую минуту, до 50 за раз. Если cron GLPI не запущен, очередь только растёт.

Решение: cron из командной строки каждую минуту (см. шаг 6 в статье как установить GLPI 11) и время от времени взгляд на Настройки > Вебхуки > Очередь вебхуков (Webhook queue на экране).

Как проверить подпись на стороне адресата

Каждая отправка содержит два заголовка: X-GLPI-timestamp (момент события) и X-GLPI-signature. Подпись — это HMAC-SHA256 от тела, за которым следует timestamp, с секретом вебхука. На Python:

import hmac, hashlib

def assinatura_valida(corpo: bytes, timestamp: str, assinatura: str, segredo: str) -> bool:
    calc = hmac.new(segredo.encode(), corpo + timestamp.encode(), hashlib.sha256).hexdigest()
    return hmac.compare_digest(calc, assinatura)

Две предосторожности: - Timestamp относится к событию, а не к отправке. При повторных попытках он повторяется. Если вы отклоняете «старые» сообщения, оставьте окно, покрывающее попытки (несколько минут). - Используйте сырое тело в том виде, в каком оно пришло. Если ваш код декодирует и заново кодирует JSON, подпись не сойдётся.

Для тех, кому нужно больше гарантий, на вкладке «Безопасность» есть проверочный вызов: перед отправкой GLPI вызывает URL с crc_token, и адресат должен ответить HMAC этого токена. Есть и OAuth (client credentials): GLPI получает токен на сервере авторизации и отправляет его как Bearer.

Когда встроенного вебхука недостаточно

• Приём данных из другой системы: нужен API.
• Логика с несколькими условиями и шагами, например «если категория X и инициатор из руководства, уведомить канал и создать задачу»: критерии фильтруют, но не выстраивают цепочку действий.
• Видеть на одном экране, что не прошло, и отправлять повторно одним кликом. Очередь показывает статус, но диагностика находится в webhook.log.

В таких случаях подключаются оркестратор вроде n8n или модуль Automations от NexTool.

Чек-лист перед включением в продуктиве

1. Адресат по HTTPS, на стандартном порту, без :porta в URL.
2. Заголовок Content-Type: application/json.
3. Подпись проверяется на стороне адресата, по сырому телу и с временным окном для попыток.
4. Критерии, чтобы вебхук не срабатывал на всё подряд.
5. «Количество попыток» в зависимости от важности (3 — хорошее начало).
6. Cron GLPI запускается каждую минуту.
7. «Запись в историю элемента» включена, чтобы специалист видел, что было отправлено.
8. Тест на вымышленной заявке, прежде чем открывать для всех.

Тест NexTool от 3 октября 2026 г. в GLPI 11.0.7 нашей поддержки, тестовая организация с вымышленными данными. Тестовые вебхуки и заявки затем были удалены. Поведение также сверено с исходным кодом GLPI 11.