IOSOR

IOSOR Wiedza

Bramka podpisu i okna replay

Bramka produkcyjna: zweryfikuj podpis i ogranicz okno replay, zanim jakikolwiek webhook stanie się prawdą o pieniądzach lub statusie — niepodpisane lub stare zdarzenia pozostają fail-closed.

Akceptowanie niezweryfikowanych lub opóźnionych webhooków naraża konta prepaid na sfałszowane salda i podwójne obciążenia wynikające z powtórzeń. Musisz wdrożyć rygorystyczną bramkę, która kryptograficznie sprawdza podpisy i odrzuca zdarzenia spoza okna czasowego przed jakąkolwiek modyfikacją środków. Powiązane: podpis webhooka i okno replay, ponowienia webhooka przychodzącego, Wspólny język statusów dla produktu i finansów, Wiersze debit a status dostawy w jednym ledger.

Weryfikacja podpisu to bramka pieniężna

Pieniądze i prawda o statusie zaczynają się dopiero po przejściu kontroli podpisu. Brakujące, niedopasowane lub pominięte podpisy kończą się zamknięciem — brak wiersza w księdze, brak «dostarczono mimo wszystko do pilota». Catalog Live nie znosi bramki. Głębia nawyków: podpis webhooka i okno replay. Miękkie USD 1000/miesiąc traktuje «akceptowanie niepodpisanych na stage na zawsze» jako dług produkcyjny; USD 20 dowodzi, że jeden sfałszowany body nigdy nie zaksięguje debetu.

Okno replay przed prawdą o statusie

Sprawdzenie bramki Zaliczenie oznacza Odrzucenie oznacza
Podpis obecny + ważny Zdarzenie uwierzytelnione Odrzuć; brak zapisu pieniędzy/statusu
Znaczniki czasu w oknie Wystarczająco świeże do zaufania Odrzuć jako replay/przestarzałe
ID zdarzenia nieznane Pierwsza akceptacja ACK bez drugiego debetu
Zdarzenie umowne na liście W menu zdarzeń kupującego Odrzuć nieznany typ

Dostarczenie at-least-once wywoła ponowienie. Spóźnione ponowienie poza oknem to nie «może dostarczono». Loguj odrzucenia okna oddzielnie od błędów podpisu. Głębia ponowień: ponowienia webhooka przychodzącego.

Fail-closed gdy bramka odrzuca

Odrzucone zdarzenia nigdy nie wymyślają sukcesu. Produkt i finanse dzielą te same słowa odrzucenia — żadnych bohaterskich kodów upstream: Wspólny język statusów dla produktu i finansów. Wiersze debetu pozostają zgodne tylko z zaakceptowanymi zdarzeniami: Wiersze debit a status dostawy w jednym ledger. Efekty uboczne tylko po ACK; praca CRM przed bramką tworzy podwójną prawdę.

Produkt, finanse i ops dzielą jeden dowód

Produkt: czy legalne, podpisane zdarzenie w oknie może raz zaktualizować status? Finanse: czy każde zdarzenie wpływające na pieniądze pokazuje przejście bramki w tym samym oknie UTC? Ops: eksportuj błędy podpisu kontra odrzucenia okna bez archeologii na Slacku.

Lista kontrolna kupującego dla bramki podpisu i replay

Zweryfikuj rotację klucza HMAC w środowisku staging. Upewnij się, że dryf znacznika czasu nie przekracza bufora replay. Sprawdź, czy handler webhooka zapisuje ID zdarzenia, aby uniknąć podwójnego przetwarzania. Przetestuj sfałszowany payload, aby potwierdzić, że bramka chroni rejestr debetów.

Zacznij z IOSOR

W konsoli: Signature + replay window gate before first webhook accept.. Nazwij właściciela i bramki przed skalowaniem.

Powiązane: webhook signature replay window inbound sms webhook retries idempote

Podsumowanie IOSOR

Dyscyplina ops na dyżur—nie brochure.

Zrób: name owner + gate. Nie: skip the gate.

Czy ten przewodnik był pomocny?

Powiązane przewodniki