IOSOR

IOSOR Знания

Подпис на уебхук и прозорец за повторение: идемпотентност, за да остане 02:00 скучно

Проверявайте подписи, ограничете прозореца за повторение и правете входящите уебхукове идемпотентни — никога не приемайте неподписани callback, никога не дебитирайте prepaid два пъти на retry.

Неподписаните уебхукове са просто неавтентифициран трафик, който често води до скъпи грешки като дублирани транзакции или дебити в 02:00 часа. За да избегнете тези инциденти, задължително прилагайте стриктна проверка на подписа, задайте разумен прозорец за повторение и използвайте ключове за идемпотентност. Тези скучни, но критични навици превръщат интеграциите ви в надеждни системи, които преминават успешно всеки финансов одит. Научете повече за webhooks and keys at launch и webhooks that survive launch.

Неподписаните callback не са събития

Проверете подписа преди да парсвате бизнес полета. Отхвърлете липсващи, изтекли или криви подписи с client-safe грешка — не обработвайте «все пак за пилота». Staging потребител, който прескача проверката, учи производството да прескача. Каталог live за съобщения не значи, че URL на уебхука е обществено сметище. Ако не докажете кой е подписал тялото, нямате събитие; имате фалшива заявка.

Прозорци за повторение и защо се случва 02:00

Доставка поне-веднъж retried при timeout, 5xx и нееднозначна мрежова загуба. Късен retry в 02:00 е нормален. Прозорецът ограничава колко дълго подписан payload остава приемлив: твърде широк и нападател повтаря стар STOP; твърде тесен и легитимен retry изглежда фалшификация. Записвайте отхвърляния на прозорец отделно от грешки на подпис.

Идемпотентност, която финансите четат

Същото ID на събитие трябва да даде същото крайно състояние. Извлечете ID на събитие/съобщение на платформата — не измисляйте ключ от времеви печат плюс тяло. Върнете успех на известно ID без нов дебит. Изходящите изпращания се нуждаят от същата дисциплина — идемпотентност, повторения и пари.

Ротация на подпис без хаос на двойно приемане

Ротирайте тайни без прозорец, в който стари и нови подписи се приемат завинаги. Планирайте припокриване, после режете. Никога не лепете производствена тайна в билет. Разделете sandbox и производствени потребители. Dead-letter с инструменти за повторение, за да може ops отново да кара неуспешен потребител без да измисля втори дебит.

Червени флагове

  • Handler приема неподписани тела «засега»
  • Няма прозорец за повторение, или един в седмици
  • Презапис на статус без сравнение на печати
  • Странични ефекти CRM/имейл преди ACK
  • Производствена тайна в чата
  • Дублирани ID на събития миналия месец без надзор
  • Грешки към клиента, които сипят сурови upstream кодове

Започнете с IOSOR

Отворете конзолата си в IOSOR и проверете настройките на активния уебхук край Обучаващите за входящи разписки за доставка и събития за обратни извиквания. Задайте тесен прозорец за повторно изиграване при проверка на подписа от пет минути и обвържете вашия обраборчик строго с идентификатора на събитието в платформата.

Обобщение IOSOR

Непроверените уебхук обраборчици и липсващите прозорци за повторно изиграване превръщат рутинните мрежови опити в уязвимости на сигурността и дублирани промени в състоянието. Обвързването на валидността на подписа по времеви щампи и налагането на стриктна идепотентност гарантират, че автоматизираните опити за доставка в 02:00 часа остават напълно предсказуеми.

Полезно ли беше ръководството?

Свързани ръководства