Mfumo wa Cloudflare wa changamoto za bot (bot-challenge) unaweza kusitisha kimyakimya utumaji wa fomu za HTML za kawaida, na kubadilisha mbofyo rahisi wa malipo kuwa njia isiyofika popote kwa watumiaji halisi. Kubadilisha ombi kutoka kwenye navigation POST ya asili kwenda mtiririko wa fetch-first kunarejesha uzoefu huo bila kuathiri usalama.

Kwa nini tatizo hili ni muhimu

Mvumbuzi (developer) alitoa fomu ya malipo ambayo ilifanya kazi katika kila seti ya majaribio, kwa kutumia curl, na kwenye seva ya ndani. Fomu hiyo hiyo, mteja alipotumia Chrome, ilitoa kosa la usalama baada ya mbofyo wa kwanza na ujumbe wa “timeout-or-duplicate” kwenye mbofyo wa pili. Kufeli huku kulilazimu toleo tatu za marekebisho ya haraka (hot-fix) na siku nzima ya uchunguzi (debugging).

Upande wa siri wa "edge"

Fomu hiyo ipo kwenye kifurushi cha Astro cha chanzo huru (open-source) kinachotegemea kipengele cha <form> cha HTML cha kawaida. Mtumiaji anapobofya Pay, seva inajibu kwa 303 redirect kwenda Stripe, na kivinjari (browser) hufuata redirect hiyo bila kutumia JavaScript yoyote. Tovuti hutumia mfumo huu kama mbadala wakati skripti zimezimwa.

Cloudflare imekaa mbele ya tovuti na kuendesha injini ya utambuzi wa bot. Kwa maombi ya GET ya kawaida, inaweza kuonyesha changamoto ya mpito (interstitial challenge) kama vile CAPTCHA au ukaguzi wa JavaScript. Baada ya kivinjari kupita changamoto hiyo, ombi huendelea.

Hata hivyo, navigation POST haiwezi kusitishwa kwa ajili ya changamoto na kisha kuendelea ikiwa na mwili (body) wake ukiwa salama. "Edge" huitupia ombi hilo na kurudisha hali ya 503, na kuacha kivinjari na ukurasa mtupu au kosa la jumla. Vivinjari vya majaribio ya kiotomatiki, ambavyo vina sifa (fingerprint) zilezile ambazo Cloudflare inaamini, havichochei changamoto hiyo, hivyo tatizo linabaki kuwa lisiloonekana hadi mtumiaji halisi anapofika kwenye tovuti.

Kile ambacho logi zilifichua

Ufuatiliaji wa mtandao (network trace) wa moja kwa moja kutoka kwa kikao cha Chrome cha mtumiaji ulionyesha maombi mawili tofauti kwenda mwisho mmoja (endpoint):

  • Navigation POST → jibu la 503, tab ilikwama.
  • fetch() POST → ombi lilikamilika.

Maombi yote mawili yalitoka kwenye chanzo (origin) kilekile, yalibeba utambulisho (credentials) zilezile, na yalifanyika wakati ule ule. Tofauti pekee ilikuwa njia ya usafirishaji. Ombi la fetch lilipita mtiririko wa mpito unaozuia navigation POSTs.

Njia ambazo hazikuleta matokeo

Mvumbuzi alijaribu mfululizo wa marekebisho ambayo hayakugusia chanzo cha tatizo:

  • Kufanya upya tokeni za Turnstile, akidhani zimeisha muda.
  • Kuweka anwani za IP kwenye orodha nyeupe (whitelisted), akifikiri kizuizi kilikuwa kulingana na eneo.
  • Kuzima viambatanisho (extensions), kufuta service workers, na kufuta kuki (cookies).

Kila mabadiliko uliacha kosa lilelile kwa sababu kufeli huku kulitokea upande wa juu (upstream) kwenye edge, si kwenye kodi ya mteja au seva.

Marekebisho ya kiutendaji

Badala ya kuzima ulinzi wa Cloudflare, fomu hiyo ilirekebishwa kutumia mfumo wa fetch-first:

  1. Kusanya data ya fomu na uitume kwa kutumia fetch() kama JSON payload.
  2. Shughulikia jibu la seva. Ikiwa seva inarudisha URL ya lango la malipo (payment gateway), itisha location.assign() ili kuelekea huko kwa ombi rahisi la GET.

Maombi ya fetch hayachochei changamoto ya mpito, hivyo POST inafika kwenye seva ya chanzo (origin server). Redirect inayofuata ya GET inaweza kupita kwa usalama katika changamoto yoyote, kwani miili (bodies) ya GET ni tupu na inaweza kurudiwa baada ya mtumiaji kupita changamoto.

Hatari kwa watengenezaji

  • Uaminifu wa mtumiaji: Fomu ya malipo inayofeli kimyakimya inaharibu imani na inaweza kusababisha upotevu wa mapato.
  • Gharama za matengenezo: Tukio hilo lililazimu matoleo matatu ya marekebisho na siku nzima ya uchunguzi.
  • Upungufu wa majaribio: Kutegemea mazingira ya majaribio ya ndani pekee kunaweza kukosa kufeli kwa hali za nadra (edge-case) ambazo zinaonekana tu katika matumizi halisi.

Mafunzo kwa jamii pana

  • Tumia vivinjari halisi. Wakati tatizo linatokea kwa watumiaji halisi pekee, nakala logi za mtandao kutoka kwa vikao hivyo badala ya kuamini majaribio ya kiotomatiki.
  • Chukulia edge kama sehemu ya stack. Cloudflare imekaa kati ya mteja na seva; tabia yake inaathiri jinsi maombi yanapaswa kuundwa.
  • Chagua njia sahihi ya usafirishaji. Navigation POSTs na fetch POSTs husafiri kupitia njia tofauti kwenye edge. Sanifu API ukiwa na tofauti hiyo akilini.
  • Onyesha maelezo ya kosa. Onyesha ujumbe wa 503 au “timeout-or-duplicate” kwenye UI ili watengenezaji waweze kuona aina kamili ya kufeli bila kuchimba kwenye logi.

Nini cha kufuatilia baadaye

Watengenezaji wanapaswa kukagua mifumo yoyote ya fomu inayotegemea navigation POST ya asili, hasa wakati Cloudflare au huduma za usalama za CDN zinazofanana zimekaa mbele ya tovuti. Kuongeza kifuniko chepesi (lightweight fetch wrapper) kunaweza kuzuia kufeli kama huku. Zana za ufuatiliaji zinazokamata hali za (status codes) zinazozalishwa na edge zitatoa ishara ya tatizo kabla halijamfikia wateja.

Muhtasari: Changamoto za bot za Cloudflare zinapokuwa hai, uwasilishaji wa fomu ya HTML wa kawaida uko hatarini kupata hitilafu isiyoonekana. Kuongoza upya POST kupitia fetch() na kukamilisha mtiririko kwa mwelekezo wa GET huepuka ukomo wa edge huku ukihakikisha usalama unabaki vilevile. Chukulia edge kama kodi, siyo tu hatua ya mtandao, na uunde njia zako za usafirishaji kulingana na hilo.