Проверка подписи webhook за прокси
Версия 2.7
Порядок проверки запроса
На входе обработчика прочитайте X-RD-Signature и X-RD-Timestamp. Возьмите необработанное тело HTTP-запроса. Соберите подписываемую строку из timestamp, точки и этих данных. Вычислите HMAC-SHA256 с секретом webhook и сравните подпись в постоянное время. Проверьте, что отклонение часов укладывается в 300 секунд. После проверки разберите содержимое и передайте событие в обработку.
Что прокси может изменить
Сравните байты, полученные на первом компоненте, с байтами, которые использует обработчик. Если middleware читает JSON и собирает его обратно, могут измениться пробелы, порядок полей, экранирование и окончания строк. Такие преобразования дают другую подпись даже при эквивалентном объекте. Настройте доступ к исходному телу перед JSON-парсингом. Диагностику преобразований выполняйте на синтетическом примере.
Отклонение системных часов
При частых отклонениях timestamp проверьте часы процесса и узла, где выполняется верификация. Сопоставьте их с временем получения события в журнале. Если ошибка возникает только на одном экземпляре, проверьте настройки синхронизации времени именно на нём. Расширение окна наугад ухудшает защиту от повторной отправки. При разборе фиксируйте разницу в секундах и время с часовым поясом.
Разбор HOOK-401
HOOK-401 указывает на подпись, которая не прошла проверку. Проверьте, что обработчик использует секрет нужной среды и что в вычисление попало исходное тело. Проверьте заголовки и рассинхронизацию времени. Если сообщение прошло через шлюз и проверка упала после обновления middleware, воспроизведите путь запроса в тестовом контуре с известным синтетическим событием.
Безопасная диагностика
Сохраните идентификатор события, время, код ответа, признак наличия обязательных заголовков и сведения о версии обработчика. Тело запроса может содержать сведения о получателе. В рабочих логах достаточно фиксировать размер сообщения и вид ошибки, чтобы локализовать отказ. При обращении в поддержку передавайте event_id и время ошибки без секрета или полного тела события. Если проблема только у одной реплики, добавьте её технический идентификатор.
Контроль после обновления клиента
Повторите проверку через тот же шлюз, который используется в рабочем маршруте. На синтетическом событии измените один пробел в теле после расчёта подписи и убедитесь, что обработчик отклоняет запрос. Затем проверьте неизменённый пример. Оба случая должны проходить через одинаковые middleware и попадать в журнал с понятным результатом.
Ротация секрета webhook
Согласуйте момент обновления секрета отправителя и обработчика и проверьте готовность всех экземпляров. После изменения найдите контрольную доставку в журнале, затем проверьте, что она появилась в очереди. При сбое сравните время изменения с началом ошибок подписи. Если есть отложенные доставки, анализируйте их по event_id и времени попытки.