IOSOR

IOSOR Kunnskap

Webhook-signatur og replayvindu: idempotens så 02:00 forblir kjedelig

Verifiser signaturer, begrens replayvinduet og gjør innkommende webhooks idempotente — godta aldri usignerte callbacks, debitér aldri prepaid to ganger på et retry.

En usignert callback er ikke en hendelse. Det er uautentisert HTTP som tilfeldigvis ligner payloaden deres. Lag som «godtar først, verifiserer senere» betaler kl. 02:00: en gjenavspilt DLR, en duplisert STOP eller en andre lommebok-debit finance ikke kan rulle tilbake. Prepaid gjør feilen penge-synlig. Kjedelige vaner: signatur på hver forespørsel, begrenset replayvindu, idempotensnøkler finance leser ved siden av ledger-linjen.

IOSOR forventer reviderbare B2B-integrasjoner: signerte webhooks, roterbare hemmeligheter, client-safe feil uten fremmede merker. Nær USD 1,000+ månedsbruk blir korrelasjons-ID-er og replaybevis kommersielt gjennomgangsmateriale.

Usignerte callbacks er ikke hendelser

Verifiser signaturen før dere parser forretningsfelt. Avvis manglende, utløpte eller skjeve signaturer med en client-safe feil — behandle ikke «likevel for piloten». En staging-konsument som hopper over verifikasjon, trener produksjon til å hoppe over. Meldingskatalog live betyr ikke at webhook-URL-en er en offentlig fylling.

Replayvinduer og hvorfor 02:00 skjer

Levering minst-én-gang retried ved timeout, 5xx og tvetydig nett-tap. Et sent retry kl. 02:00 er normalt. Vinduet begrenser hvor lenge en signert payload forblir akseptabel: for bredt og en angriper spiller en gammel STOP; for smalt og et legitimt retry ligner forfalskning. Logg vindusavvisninger atskilt fra signaturfeil.

Idempotens finance kan lese

Samme hendelses-ID må gi samme slutt-tilstand. Trekk ut plattformens hendelses-/melding-ID — finn ikke opp en nøkkel av tidsstempel pluss kropp. Returner suksess på et kjent ID uten å debitere igjen. Utgående sendinger trenger samme disiplin — idempotens, nytt forsøk og penger. Finance skal forklare hver prepaid-linje mot en statushendelse.

Signaturrotasjon uten dual-accept-kaos

Roter hemmeligheter uten et vindu der gamle og nye signaturer aksepteres for evig. Planlegg overlapping, klipp deretter. Lim aldri en produksjonshemmelighet inn i en sak. Skill sandbox- og produksjonskonsumenter. Dead-letter med replayverktøy så ops kan kjøre en mislykket konsument om uten å finne opp en andre debit. Bær korrelasjons-ID-er fra sending til ledgerlinje så 02:00 er et runbook, ikke arkeologi.

Røde flagg

  • Handler godtar usignerte kropper «foreløpig»
  • Ingen replayvindu, eller ett målt i uker
  • Statusoverskriving uten tidsstempel-sammenligning
  • CRM/e-post-bivirkninger før ACK
  • Produksjonshemmelighet i chatten
  • Dupliserte hendelses-ID-er forrige måned uten tilsyn
  • Kundefeil som spiller rå upstream-koder

Start med IOSOR

Åpne IOSOR-konsollet ditt og sjekk innstillingene for det aktive webhook-endepunktet for innkommende leveringskvitteringer og hendelsestilbakekall. Sett et stramt signaturverifiseringsvindu for gjenavspilling på fem minutter, og bind håndtereren strengt til plattformens hendelses-ID. Test endepunktet mot gjenavpilte nyttelastene i stagingmiljøet for å sikre at duplikater returnerer en 200 OK uten å utløse redundant forretningslogikk.

IOSOR-lærdom

Uverifiserte webhook-håndterere og manglende gjenavspillingsvinduer forvandler rutinemessige nettverksforsøk til sikkerhetssårbarheter og dupliserte tilstandsendringer. Ved å begrense signaturgyldigheten etter tidsstempel og håndheve streng idempotens sikrer du at automatiserte leveringsforsøk klokken 02:00 forblir fullstendig forutsigbare.

Var denne guiden nyttig?

Relaterte veiledninger