IOSOR Gabay
Velocity caps bago ang production OTP
Limitahan ang production OTP gamit ang velocity at cooldown bago maubos ang prepaid wallet — caps base sa identity, destination, at window, na may tapat na status ng limit.
Ang production OTP na walang velocity caps ay parang gripo na walang kontrol sa prepaid. Ang mga cap ay dapat ilagay bago ang Live volume — hindi pagkatapos magtanong ng finance kung bakit nawala ang pondo. Ang pahinang ito ay ang velocity gate: sino, saan, gaano kabilis — iba ito sa TTL/resend mechanics at sa two-debit verify story.
Kaugnay: TTL ng OTP at cooldown sa muling padala, debit ng paghatid ng OTP laban sa verify session, Abuso sa OTP: mga unang kontrol sa landas ng mamimili, mga hangganan ng wallet bago ang production traffic, gabay laban sa abuso at gastos sa OTP.
Hindi pareho ang velocity sa TTL
Ang TTL ay sumasagot kung gaano katagal mabubuhay ang code. Ang velocity ay sumasagot kung ilang intents ang maaaring gawin ng isang identity o destination sa loob ng isang window. Ang cooldown ay nagbibigay ng espasyo sa resends; ang velocity caps ay naglilimita sa burst na hindi dapat magsimula. Ang pagkalito sa dalawa ay nag-iiwan ng butas na nag-aubos ng wallet habang sumusunod sa TTL. Panatilihin ang pareho — at pangalanan kung aling gate ang nag-fire sa status.
Caps base sa identity, destination, at window
| Cap | Tanong sa Window | Fail closed kahulugan |
|---|---|---|
| Per identity | Ilang OTP intents / oras? | Honest rate-limited |
| Per destination | High-cost corridor burst? | Corridor blocked |
| Per IP / device | Bot-shaped minting? | Challenge o reject |
| Wallet stop-line | Lampas na sa limit? | Hold refuses send |
I-gate ang prod OTP bago ang Live language
Huwag i-set ang production OTP sa Live habang draft pa ang velocity caps. Ang green smoke sa isang happy path ay hindi patunay ng velocity. Kinakailangan: configured caps, fail-closed tested, export row na nagpapakita kung aling cap ang nag-fire, at ang finance ay kayang i-join ang limited intent sa hold. Launch honesty: Kapag harang ang paglulunsad: katayuan nang walang pagsisinungaling.
Tapat na limit status para sa produkto at finance
Kapag nag-fire ang isang cap, ang status ay dapat magpakita ng malinaw na rejection. Ang product at finance ay gumagamit ng parehong wika (Magkakaparehong wika ng status para sa produkto at pananalapi). Ang mga retry sa ilalim ng parehong idempotency key ay hindi dapat makalusot sa cap.
Checklist ng mamimili para sa velocity caps
Siguraduhin na ang bawat corridor ay may takdang limit bago magsimula ang production traffic. I-test ang scenario kung saan naabot ang limit at kumpirmahin na tinatanggihan ng system ang mga request nang walang exemption. Dapat makita ng finance ang hold status bago maubos ang wallet.
Magsimula sa IOSOR
Buksan ang konsol ng IOSOR at i-configure ang mga panuntunan para sa velocity cap sa pagitan ng pagkakakilanlan, destinasyon, at hanay ng IP bago i-promote sa produksyon ang iyong OTP pipeline. Magsagawa ng simulate na burst test upang matiyak na ang mga limitasyon sa bilis ay nagbabalik ng agaran o tinanggihang estado sa pamamagitan ng webhook. Tiyaking hinaharangan ng iyong deployment gate ang produksyon hanggang sa ang bawat window ng layunin ay tama at sarado kapag nabigo.
Buod ng IOSOR
Ipinatunayan ng artikulong ito na ang TTL lamang ay hindi kayang protektahan ang iyong OTP pipeline mula sa mga biglaang bugso ng layunin. Ang mabisang proteksyon sa ruta ay nangangailangan ng mga natatanging velocity cap na nakamapa sa mga account, destinasyon, at pamilya ng IP, na nagpapatupad ng mahigpit na hangganan bago umabot sa produksyon ang trapiko.
Nakatulong ba ang gabay na ito?
Mga kaugnay na gabay
- Paglilipat ng mga Panuntunan sa Limitasyon sa Panlilinlang Habang May Handover ang Engineering Team
I-audit ang mga threshold ng operational velocity at alert contacts sa mga paglipat ng platform team para mapanatili ang tuluy-tuloy na proteksyon laban sa pang-aabuso.
- Pagtatakda ng mga Traps sa Patutunguhan Upang Matukoy ang Awtomatikong Pumping sa Pilot Phase
Mag-deploy ng mga dummy destination trigger sa unang pilot testing upang mahuli ang mga awtomatikong script at maiwasan ang mapanlinlang na pumping.
- Pagpapanumbalik ng Ligtas na Dami ng Trapiko sa Pamamagitan ng mga Detalyadong Panuntunan sa Prefix Allowlist
Matutunan kung paano ligtas na palakihin ang SMS traffic pagkatapos ng insidente ng fraud sa pamamagitan ng mahigpit na prefix allowlist, JIT number assignment, at pagsubaybay sa USD thresholds sa loob ng IOSOR.