IOSOR

IOSOR Gabay

Lagda ng webhook at replay window: idempotency para manatiling boring ang 02:00

I-verify ang mga lagda, bound ang replay window, gawing idempotent ang inbound webhook — huwag tumanggap ng unsigned callback, huwag mag-debit ng prepaid nang dalawang beses sa retry.

Ang unsigned callback ay hindi kaganapan. Ito ay hindi napatunayang HTTP na nagkataong magmukhang payload ninyo. Ang mga koponan na «tumanggap muna, i-verify mamaya» ay nagbabayad sa 02:00: naulit na DLR, duplicate STOP, o pangalawang debit ng wallet na hindi maibabalik ng finance. Ginagawa ng prepaid na pera-nakikita ang pagkabigo. Boring na ugali: lagda sa bawat kahilingan, bounded replay window, idempotency key na binabasa ng finance sa tabi ng linya ng ledger.

Inaasahan ng IOSOR ang naa-audit na B2B integration: naka-sign na webhook, naiikot na sikreto, client-safe error na hindi nagtatapon ng dayuhang brand. Malapit sa USD 1,000+ buwanang gamit, ang correlation ID at ebidensya ng replay ay nagiging materyal ng commercial review.

Ang unsigned callback ay hindi kaganapan

I-verify ang lagda bago i-parse ang business field. Tanggihan ang nawawala, stale, o mismatched na lagda ng client-safe error — huwag i-proseso «anyway for the pilot». Ang staging consumer na lumalaktaw sa verification ay nagtuturo sa production na lumaktaw. Ang katalogo live ng mensahe ay hindi nangangahulugang dump ang webhook URL.

Mga replay window at bakit nangyayari ang 02:00

Ang at-least-once delivery ay nagre-retry sa timeout, 5xx, at malabong pagkawala ng network. Ang late retry sa 02:00 ay normal. Nililimitahan ng window kung gaano katagal tinatanggap ang naka-sign na payload: masyadong malawak at magre-replay ang attacker ng lumang STOP; masyadong makitid at magmumukhang peke ang lehitimong retry. I-log ang window reject nang hiwalay sa signature fail.

Idempotency na mababasa ng finance

Ang parehong event ID ay dapat magbigay ng parehong end state. Kunin ang platform event/message ID — huwag mag-imbento ng key mula sa timestamp plus katawan. Ibalik ang tagumpay sa kilalang ID nang hindi muling nagde-debit. Kailangan ng outbound send ang parehong disiplina — idempotency, retry, at pera.

Pag-ikot ng lagda nang walang dual-accept chaos

Paikutin ang sikreto nang walang window kung saan tinatanggap magpakailanman ang luma at bagong lagda. Planuhin ang overlap, tapos putulin. Huwag idikit ang production secret sa ticket. Paghiwalayin ang sandbox at production consumer. Dead-letter na may replay tool para ma-re-drive ng ops ang nabigong consumer nang hindi nag-iimbento ng pangalawang debit.

Mga pulang bandila

  • Tumatanggap ang handler ng unsigned body «for now»
  • Walang replay window, o sinusukat sa linggo
  • Pag-overwrite ng status nang walang paghahambing ng timestamp
  • Side effect ng CRM/email bago ACK
  • Production secret sa chat
  • Duplicate event ID noong nakaraang buwan na walang tumitingin
  • Error sa kliyente na nagtatapon ng hilaw na upstream code

Magsimula sa IOSOR

Buksan ang iyong IOSOR console at suriin ang mga setting ng iyong aktibong webhook endpoint para sa mga inbound delivery receipt at event callback. Magtakda ng mahigpit na signature verification replay window na limang minuto at i-ugnay ang iyong handler nang eksakto sa platform event ID.

Buod ng IOSOR

Ang mga hindi na-verify na webhook handler at nawawalang replay window ay ginagawang mga kahinaan sa seguridad at dobleng pagbabago ng estado ang mga karaniwang retry sa network. Ang pagtatakda ng bisa ng signature ayon sa timestamp at pagpapatupad ng mahigpit na idempotency ay nagatitiyak na ang mga awtomatikong pagtatangka sa paghahatid sa ganap na 02:00 ay mananatiling predictable.

Nakatulong ba ang gabay na ito?

Mga kaugnay na gabay