HMAC webhook не сходится после разбора JSON в n8n

Поставщик событий присылает в n8n webhook о новом заказе и заголовок с HMAC-подписью. Workflow берёт разобранный $json.body, собирает JSON заново и вычисляет HMAC. Подпись не совпадает, хотя секрет верный. Изменился не смысл заказа, а байты: пробелы, переносы строк и порядок ключей после сериализации могут быть другими. HMAC проверяет точную строку байтов, которую подписал отправитель.

Сначала выясните формат подписи отправителя

Откройте описание конкретного webhook-провайдера: он может подписывать только body, body вместе с timestamp, путь запроса или строку специального формата. Выберите указанную хеш-функцию и кодирование digest — hex или base64. Не подставляйте SHA-256 по привычке. Сохраните один тестовый запрос провайдера целиком: сырые байты тела, имя заголовка, значение подписи и время. Это fixture, на котором можно проверять workflow после обновления n8n.

В Webhook node включите опцию Raw Body. Сразу после trigger выполните проверку подписи на полученном сыром теле, до Edit Fields, AI Agent и записи в CRM. Для HMAC используйте Crypto node с действием Hmac и секретом в credentials либо Code node с Node crypto, если вашей схеме нужна составная строка или сравнение с постоянным временем. В n8n Cloud модуль crypto доступен в Code node. В self-hosted n8n импорт встроенного модуля нужно разрешить через NODE_FUNCTION_ALLOW_BUILTIN=crypto; если используются task runners, задайте переменную в среде runners, а не только основного процесса n8n. В Crypto node выберите Binary File, если raw body пришло как бинарное поле; если это строка, убедитесь, что её байтовое представление совпадает с исходным запросом. Деталь зависит от контент-типа и версии узла, поэтому сравните HMAC с известным fixture до публикации.

Неверная подпись должна обрывать цепочку

В Webhook выберите режим ответа Using 'Respond to Webhook' Node. После вычисления digest сравните его с заголовком в формате провайдера. Обработайте префикс вроде sha256=, если он задан спецификацией, и проверьте равную длину перед сравнением. Неверная или отсутствующая подпись отправляется в ветку отказа, где Respond to Webhook возвращает соответствующий код без запуска AI-узлов. Только после успешной проверки разбирайте JSON и валидируйте схему события. Не помещайте HMAC-секрет, полный body с персональными данными и подпись в обычный execution log.

Три проверки быстро вскроют ошибку: исходный fixture должен проходить; тот же body с одним изменённым пробелом должен отклоняться, если отправитель подписывает точные байты; повтор с изменённым timestamp должен отклоняться для схемы, где timestamp участвует в подписи. Если провайдер включает время и ID события, добавьте ограничение давности и идемпотентную запись ID, иначе корректно подписанный старый запрос можно повторно отправить.

В платном курсе Продвинутый n8n: production-автоматизации и AI-агенты вы защищаете webhooks через HMAC и строите идемпотентную обработку событий. Здесь обе части встречаются в одном workflow: сначала доказать происхождение запроса, затем безопасно решить, обрабатывать ли повтор. Откройте программу курса, чтобы настроить интеграцию целиком.