Cloudflare-ன் bot-challenge அமைப்பு சாதாரண HTML form submissions-களை அமைதியுமாகத் தடுத்து நிறுத்தக்கூடும், இது ஒரு எளிய கட்டணச் செலுத்தும் (payment) கிளிக் செய்வதை உண்மையான பயனர்களுக்கு ஒரு முட்டுக்கட்டையாக மாற்றுகிறது. கோரிக்கையை (request) ஒரு native navigation POST-லிருந்து fetch-first flow-க்கு மாற்றுவதன் மூலம், பாதுகாப்பைக் குறைக்காமல் அனுபவத்தை மீட்டெடுக்க முடியும்.
இந்தப் பிரச்சனை ஏன் முக்கியமானது
ஒரு டெவலப்பர் ஒவ்வொரு test suite, curl மற்றும் local server ஆகியவற்றிலும் சரியாக வேலை செய்யும் ஒரு payment form-ஐ வெளியிட்டார். அதே form, ஒரு வாடிக்கையாளர் Chrome பயன்படுத்தும்போது, முதல் கிளிக் செய்தவுடன் ஒரு security error-ஐயும், இரண்டாவது கிளிக் செய்தபோது “timeout-or-duplicate” என்ற செய்தியையும் காட்டியது. இந்தத் தோல்வி மூன்று hot-fix releases மற்றும் ஒரு முழு நாள் debugging-க்கு வழிவகுத்தது.
மறைந்திருக்கும் விளிம்புநிலைச் சிக்கல்
இந்த form ஒரு open-source Astro package-ல் உள்ளது, இது ஒரு சாதாரண HTML <form> element-ஐச் சார்ந்துள்ளது. பயனர் Pay என்பதைக் கிளிக் செய்யும்போது, சர்வர் Stripe-க்கு 303 redirect-உடன் பதிலளிக்கிறது, மேலும் பிரவுசர் எந்த JavaScript இல்லாமலேயே அந்த redirect-ஐப் பின்பற்றுகிறது. ஸ்கிரிப்ட்கள் முடக்கப்பட்டிருக்கும் போது ஒரு மாற்று வழிமுறையாக (fallback) இணையதளங்கள் இந்த முறையைப் பயன்படுத்துகின்றன.
Cloudflare இணையதளத்திற்கு முன்னால் அமர்ந்து ஒரு bot-detection engine-ஐ இயக்குகிறது. சாதாரண GET requests-களுக்கு, அது ஒரு இடைநிலைச் சவாலை (interstitial challenge - ஒரு CAPTCHA அல்லது JavaScript check) காட்டக்கூடும். பிரவுசர் அந்தச் சவாலைத் தாண்டிய பிறகு, கோரிக்கை தொடர்கிறது.
இருப்பினும், ஒரு navigation POST-ஐ ஒரு சவாலுக்காக நிறுத்தி வைக்கவோ அல்லது அதன் body அப்படியே இருக்கும்படி மீண்டும் தொடங்கவோ முடியாது. edge அந்த கோரிக்கையைத் தள்ளிவிட்டு 503 status-ஐத் திருப்பி அனுப்புகிறது, இதனால் பிரவுசர் ஒரு வெற்றுப் பக்கத்தையோ அல்லது பொதுவான error செய்தியையோ காட்டுகிறது. Cloudflare நம்பும் அதே fingerprint-ஐக் கொண்ட தானியங்கி சோதனை பிரவுசர்கள் (Automated test browsers), அந்தச் சவாலைத் தூண்டுவதில்லை, எனவே ஒரு உண்மையான பயனர் இணையதளத்தைப் பயன்படுத்தும் வரை இந்தப் பிரச்சனை கண்ணுக்குத் தெரியாமல் இருக்கிறது.
லாக்ஸ் (logs) எதை வெளிப்படுத்தின
ஒரு பயனரின் Chrome session-லிருந்து எடுக்கப்பட்ட நேரடி network trace, ஒரே endpoint-க்கு இரண்டு மாறுபட்ட கோரிக்கைகளைக் காட்டியது:
- Navigation POST → 503 response, tab முடங்கியது.
- fetch() POST → request முடிவடைந்தது.
இரண்டு கோரிக்கைகளும் ஒரே origin-லிருந்து வந்தன, ஒரே credentials-களைக் கொண்டிருந்தன, மேலும் ஒரே நேரத்தில் நிகழ்ந்தன. ஒரே வித்தியாசம் அதன் தகவல் பரிமாற்ற முறை (transport method) மட்டுமே. fetch கோரிக்கை, navigation POST-களைத் தடுக்கும் இடைநிலை ஓட்டத்தைத் (interstitial flow) தவிர்த்தது.
பலனளிக்காத முயற்சிகள்
டெவலப்பர் மூல காரணத்தைத் தவறவிட்ட பல தீர்வுகளை முயன்றார்:
- Turnstile tokens காலாவதியாகிவிட்டன என்று கருதி அவற்றை புதுப்பித்தார்.
- பிளாக் (block) என்பது இடத்தின் அடிப்படையில் (location-based) இருக்கலாம் என்று நினைத்து, IP ranges-களை whitelist செய்தார்.
- Extensions-களை முடக்கி, service workers-களை நீக்கி, cookies-களை அழித்தார்.
ஒவ்வொரு மாற்றமும் பிழையை மாற்றவில்லை, ஏனெனில் தோல்வி client அல்லது server code-ல் இல்லை, மாறாக upstream-ல் edge-ல் இருந்து உருவானது.
நடைமுறைத் தீர்வு
Cloudflare-ன் பாதுகாப்பை முடக்குவதற்குப் பதிலாக, form ஒரு fetch-first pattern-ஐப் பயன்படுத்தும் வகையில் மறுவடிவமைப்பு செய்யப்பட்டது:
- form தரவுகளைச் சேகரித்து (Collect the form data), அதை
fetch()மூலம் ஒரு JSON payload-ஆக அனுப்பவும். - சர்வரின் பதிலைக் கையாளவும் (Handle the server’s response). சர்வர் payment gateway-க்கான ஒரு URL-ஐத் திருப்பிக் கொடுத்தால், ஒரு எளிய GET request மூலம் அங்குச் செல்ல
location.assign()-ஐ அழைக்கவும்.
Fetch கோரிக்கைகள் இடைநிலைச் சவாலைத் தூண்டுவதில்லை, எனவே POST கோரிக்கை அதன் origin server-ஐச் சென்றடைகிறது. அடுத்தடுத்த GET redirect-கள் எந்தச் சவாலையும் பாதுகாப்பாகக் கடந்து செல்ல முடியும், ஏனெனில் GET bodies காலியாக இருக்கும் மற்றும் பயனர் சவாலைத் தாண்டிய பிறகு அவற்றை மீண்டும் இயக்க முடியும்.
டெவலப்பர்களுக்கான பாதிப்புகள்
- User trust: அமைதியுமாகத் தோல்வியடையும் ஒரு payment form, நம்பிக்கையைச் சிதைத்து வருவாய இழப்புக்கு வழிவகுக்கும்.
- Maintenance overhead: இந்தச் சம்பவத்திற்கு மூன்று patch releases மற்றும் ஒரு முழு நாள் விசாரணை தேவைப்பட்டது.
- Testing blind spots: உள் சோதனைச் சூழல்களை (internal test environments) மட்டுமே நம்பியிருப்பது, நிஜ உலகில் மட்டுமே தோன்றும் விளிம்புநிலைத் தோல்விகளை (edge-case failures) கவனிக்கத் தவறலாம்.
பரந்த சமூகத்திற்கான பாடங்கள்
- Instrument real browsers. ஒரு பிரச்சனை உண்மையான பயனர்களுக்கு மட்டுமே தோன்றும்போது, தானியங்கி சோதனை ஓட்டங்களை (automated test runs) நம்புவதற்குப் பதிலாக, அந்த session-லிருந்து network logs-களைப் பிடிக்கவும்.
- Treat the edge as part of the stack. Cloudflare, client மற்றும் server-க்கு இடையில் அமர்ந்துள்ளது; அதன் செயல்பாடு கோரிக்கைகள் எவ்வாறு கட்டமைக்கப்பட வேண்டும் என்பதைப் பாதிக்கிறது.
- Choose the right transport. Navigation POST-கள் மற்றும் fetch POST-கள் edge-ல் வெவ்வேறு பாதைகள் வழியாகச் செல்கின்றன. அந்த வேறுபாட்டைக் கருத்தில் கொண்டு API-களை வடிவமைக்கவும்.
- Expose error details. 503 அல்லது “timeout-or-duplicate” செய்திகளை UI-ல் காட்டவும், இதனால் டெவலப்பர்கள் logs-களைத் தேடாமலேயே துல்லியமான தோல்வி முறையைப் பார்க்க முடியும்.
அடுத்து கவனிக்க வேண்டியவை
டெவலப்பர்கள், குறிப்பாக Cloudflare அல்லது அது போன்ற CDN பாதுகாப்பு சேவைகள் இணையதளத்திற்கு முன்னால் இருக்கும்போது, native POST navigation-ஐச் சார்ந்திருக்கும் எந்தவொரு form-based workflows-களையும் ஆய்வு செய்ய வேண்டும். ஒரு இலகுவான fetch wrapper-ஐச் சேர்ப்பது இத்தகைய தோல்விகளைத் தவிர்க்க உதவும். edge-லிருந்து உருவாகும் status codes-களைப் பதிவு செய்யும் கண்காணிப்பு கருவிகள் (Monitoring tools), பிரச்சனை வாடிக்கையாளர்களைச் சென்றடைவதற்கு முன்பே அதைக் கண்டறியும்.
முக்கியக் கருத்து: Cloudflare-இன் பாட் சவால்கள் (bot challenges) செயல்பாட்டில் இருக்கும்போது, சாதாரண HTML படிவ சமர்ப்பணங்கள் (form submission) எந்தத் தகவலும் தெரிவிக்காமல் தோல்வியடையும் (silent failure) அபாயம் உள்ளது. fetch() மூலம் POST கோரிக்கையை மறுவழிப்படுத்தி, ஒரு GET redirect மூலம் அந்தச் செயல்பாட்டை நிறைவு செய்வதன் மூலம், பாதுகாப்பைச் சிதைக்காமல் எட்ஜ் (edge)-இன் வரம்பைத் தவிர்க்க முடியும். எட்ஜை வெறும் நெட்வொர்க் தாவலாக (network hop) மட்டும் பார்க்காமல், ஒரு குறியீடாகக் (code) கருதி, அதற்கேற்ப உங்கள் போக்குவரத்து முறைகளை (transports) வடிவமைக்கவும்.