IOSOR

IOSOR Znalosti

Podpis webhooku a okno replay: idempotence, aby 02:00 zůstalo nudné

Ověřujte podpisy, omezte okno replay a udělejte příchozí webhooky idempotentní — nikdy nepřijímejte nepodepsané callbacky, nikdy nedeitujte prepaid dvakrát na retry.

Nepodepsaný callback není událost. Je to neautentizované HTTP, které náhodou vypadá jako váš payload. Týmy, které «nejdřív přijmou, pak ověří», platí v 02:00: přehráté DLR, zdvojené STOP nebo druhý debit peněženky, který finance nevrátí. Prepaid činí chybu viditelnou v penězích. Nudné zvyky: podpis na každém požadavku, omezené okno replay, klíče idempotence, které finance čte vedle řádku ledgeru.

IOSOR očekává auditovatelné B2B integrace: podepsané webhooky, rotovatelné tajemství, client-safe chyby bez cizích značek. Blízko USD 1,000+ měsíčního užití se ID korelace a důkaz replay stávají materiálem commercial review. Párujte s webhooky a klíče při spuštění a webhooky, které přežijí spuštění.

Nepodepsané callbacky nejsou události

Ověřte podpis, než parsujete obchodní pole. Odmítněte chybějící, prošlé nebo nesladěné podpisy client-safe chybou — nezpracovávejte «přesto pro pilota». Staging konzument, který přeskakuje ověření, učí produkci přeskakovat. Katalog live zpráv neznamená, že URL webhooku je veřejná skládka. Pokud neprokážete, kdo podepsal tělo, nemáte událost; máte padělaný požadavek.

Okna replay a proč se stává 02:00

Doručení alespoň-jednou retried při timeout, 5xx a nejednoznačné ztrátě sítě. Pozdní retry v 02:00 je normální. Okno omezuje, jak dlouho podepsaný payload zůstává přijatelný: příliš široké a útočník přehraje staré STOP; příliš úzké a legitimní retry vypadá jako padělek. Logujte odmítnutí okna zvlášť od chyb podpisu. Viz opakování příchozího webhooku. Odpovězte rychle, persistujte nejdřív, zpracujte async — handler, který dělá CRM před ACK, vyrábí duplikáty.

Idempotence, kterou finance přečte

Stejné ID události musí dát stejný koncový stav. Vytáhněte ID události/zprávy platformy — nevymýšlejte klíč z razítka plus těla. Vraťte úspěch na známém ID bez opětovného debitu. Odchozí odeslání potřebují stejnou kázeň — idempotence, opakování a peníze. Finance má vysvětlit každý prepaid řádek proti stavové události. Pokud timeout způsobí bouři retry klienta, ledger ukáže škodu první. Katalog in setup není výmluva přeskočit idempotenci «do Live».

Rotace podpisu bez chaosu dvojí akceptace

Rotujte tajemství bez okna, kde staré i nové podpisy jsou přijímány navždy. Naplánujte překryv, pak řežte. Nikdy nevkládejte produkční tajemství do tiketu. Oddělte sandbox a produkční konzumenty. Dead-letter s nástroji replay, aby ops mohl znovu jet neúspěšného konzumenta bez vymýšlení druhého debitu. Neste ID korelace od odeslání k řádku ledgeru, aby 02:00 bylo runbook, ne archeologie.

Červené vlajky

  • Handler přijímá nepodepsaná těla «prozatím»
  • Žádné okno replay, nebo měřené v týdnech
  • Přepis stavu bez porovnání razítek
  • Vedlejší účinky CRM/e-mail před ACK
  • Produkční tajemství v chatu
  • Zdvojená ID událostí minulý měsíc bez dohledu
  • Chyby klientovi sypající surové upstream kódy

Začněte s IOSOR

Otevřete konzoli IOSOR a zkontrolujte nastavení aktivního webhookového koncového bodu pro příchozí potvrzení doručení a událostní zpětná volání. Nastavte přísné pětinutové okno pro ověření platnosti podpisu proti opakovanému přehrání a svažte svůj obslužný program přímo s ID události platformy. Otestujte koncový bod v přípravném prostředí pomocí opakovaně odeslaných dat, abyste ověřili, že duplicity vrací stav 200 OK, aniž by spouštěly zbytečnou obchodní logiku.

Shrnutí IOSOR

Neověřené obslužné programy webhooků a chybějící okna pro opětovné přehrání mění běžné síťové pokusy v bezpečnostní zranitelnosti a duplicitní změny stavu.

Byl tento průvodce užitečný?

Související průvodci