IOSOR

IOSOR Wiedza

Podpis webhooka i okno replay: idempotencja, by 02:00 było nudne

Weryfikujcie podpisy, ograniczcie okno replay i czyńcie webhooki wejściowe idempotentnymi — nigdy nie przyjmujcie callbacków bez podpisu, nigdy nie obciążajcie prepaid dwa razy na retry.

Callback bez podpisu nie jest zdarzeniem. To nieautentykowane HTTP, które przypadkiem wygląda jak wasz payload. Zespoły, które «najpierw przyjmują, potem weryfikują», płacą o 02:00: powtórzone DLR, zduplikowany STOP albo drugi debit portfela, którego finanse nie cofną. Prepaid czyni awarię widoczną w pieniądzu. Nudne nawyki: podpis na każdym żądaniu, ograniczone okno replay, klucze idempotencji, które finanse czytają obok linii ledgeru.

IOSOR oczekuje audytowalnych integracji B2B: podpisane webhooki, rotowalne sekrety, błędy client-safe bez obcych marek. Przy ok. USD 1,000+ miesięcznego użycia ID korelacji i dowód replay stają się materiałem commercial review.

Callbacki bez podpisu nie są zdarzeniami

Weryfikujcie podpis zanim sparsujecie pola biznesowe. Odrzucajcie brakujące, przeterminowane lub rozjechane podpisy błędem client-safe — nie przetwarzajcie «i tak dla pilota». Konsument stagingu, który omija weryfikację, uczy produkcję omijać. Katalog live wiadomości nie znaczy, że URL webhooka to publiczny zsyp. Jeśli nie udowodnicie, kto podpisał body, nie macie zdarzenia; macie sfałszowane żądanie.

Okna replay i dlaczego zdarza się 02:00

Dostawa co-najmniej-raz retried przy timeout, 5xx i niejednoznacznej utracie sieci. Późny retry o 02:00 jest normalny. Okno ogranicza, jak długo podpisany payload pozostaje akceptowalny: za szerokie i atakujący odtwarza stary STOP; za wąskie i legalny retry wygląda jak fałszerstwo. Logujcie odrzucenia okna osobno od błędów podpisu.

Idempotencja, którą finanse odczytają

To samo ID zdarzenia musi dać ten sam stan końcowy. Wyciągnijcie ID zdarzenia/wiadomości platformy — nie wymyślajcie klucza ze znacznika czasu plus body. Zwracajcie sukces na znanym ID bez ponownego obciążenia. Wysyłki wychodzące potrzebują tej samej dyscypliny — idempotencja, ponowienia i pieniądze.

Rotacja podpisu bez chaosu podwójnej akceptacji

Rotujcie sekrety bez okna, w którym stare i nowe podpisy są akceptowane na zawsze. Zaplanujcie nachodzenie, potem tnijcie. Nigdy nie wklejajcie sekretu produkcji do zgłoszenia. Oddzielcie konsumentów sandbox i produkcji. Dead-letter z narzędziami replay, by ops mógł ponownie pędzić nieudanego konsumenta bez wymyślania drugiego debitu.

Czerwone flagi

  • Handler przyjmuje niepodpisane body «na razie»
  • Brak okna replay albo okno w tygodniach
  • Nadpis statusu bez porównania znaczników czasu
  • Skutki CRM/e-mail przed ACK
  • Sekret produkcji na czacie
  • Zduplikowane ID zdarzeń w zeszłym miesiącu bez nadzoru
  • Błędy do klienta wylewające surowe kody upstream

Zacznij z IOSOR

Otwórz konsolę IOSOR i sprawdź aktywne ustawienia punktu końcowego webhooka dla przychodzących potwierdzeń doręczenia oraz wywołań zdarzeń. Ustaw ciasne okno ponawiania weryfikacji sygnatury na pięć minut i powiąż swój obsługiwacz ściśle z identyfikatorem zdarzenia platformy.

Podsumowanie IOSOR

Niezweryfikowane procedury obsługi webhooków i brak okien powtórzeń zamieniają rutynowe ponowienia sieciowe w luki w bezpieczeństwie oraz prowadzą do podwójnych zmian stanu. Ograniczenie ważności sygnatury według znacznika czasu oraz egzekwowanie ścisłej idempotencji sprawiają, że zautomatyzowane próby dostarczenia o godzinie 02:00 pozostają całkowicie przewidywalne.

Czy ten przewodnik był pomocny?

Powiązane przewodniki