Cloudflare ની bot-challenge સિસ્ટમ સામાન્ય HTML ફોર્મ સબમિશનને શાંતિથી નિષ્ફળ બનાવી શકે છે, જેનાથી સાચા વપરાશકર્તાઓ માટે એક સરળ પેમેન્ટ ક્લિક પણ અંતિમ અવરોધ બની શકે છે. રિક્વેસ્ટને નેટિવ નેવિગેશન POST થી fetch-first ફ્લોમાં બદલવાથી સુરક્ષા સાથે સમાધાન કર્યા વિના અનુભવ પુનઃસ્થાપિત થાય છે.
આ સમસ્યા શા માટે મહત્વની છે
એક ડેવલપરે પેમેન્ટ ફોર્મ રિલીઝ કર્યું જે દરેક ટેસ્ટ સૂટ, curl અને લોકલ સર્વર પર કામ કરતું હતું. જ્યારે ગ્રાહકે Chrome નો ઉપયોગ કર્યો ત્યારે તે જ ફોર્મે પ્રથમ ક્લિક પછી સુરક્ષા ભૂલ (security error) અને બીજા ક્લિક પર “timeout-or-duplicate” મેસેજ આપ્યો. આ નિષ્ફળતાને કારણે ત્રણ હોટ-ફિક્સ રિલીઝ અને ડિબગિંગ માટે આખો દિવસ બગાડવો પડ્યો.
છુપાયેલું એજ
આ ફોર્મ એક ઓપન-સોર્સ Astro પેકેજમાં છે જે સાદા HTML <form> એલિમેન્ટ પર આધારિત છે. જ્યારે વપરાશકર્તા Pay પર ક્લિક કરે છે, ત્યારે સર્વર Stripe પર 303 રીડાયરેક્ટ સાથે જવાબ આપે છે, અને બ્રાઉઝર કોઈપણ JavaScript વગર રીડાયરેક્ટને અનુસરે છે. જ્યારે સ્ક્રિપ્ટ્સ ડિસેબલ હોય ત્યારે સાઇટ્સ આ પેટર્નનો ઉપયોગ ફોલબેક તરીકે કરે છે.
Cloudflare સાઇટની આગળ રહે છે અને bot-detection એન્જિન ચલાવે છે. સામાન્ય GET રિક્વેસ્ટ માટે તે ઇન્ટરસ્ટીશિયલ ચેલેન્જ (એક CAPTCHA અથવા JavaScript ચેક) બતાવી શકે છે. બ્રાઉઝર ચેલેન્જ પાસ કર્યા પછી, રિક્વેસ્ટ આગળ વધે છે.
જોકે, નેવિગેશન POST ને ચેલેન્જ માટે રોકી શકાતું નથી અને પછી તેના બોડી (body) સાથે ફરીથી શરૂ કરી શકાતું નથી. એજ (edge) રિક્વેસ્ટને ડિસ્કાર્ડ કરે છે અને 503 સ્ટેટસ રિટર્ન કરે છે, જેનાથી બ્રાઉઝર પાસે ખાલી પેજ અથવા સામાન્ય એરર રહી જાય છે. ઓટોમેટેડ ટેસ્ટ બ્રાઉઝર્સ, જે Cloudflare પર વિશ્વાસ કરે છે તેવા જ ફિંગરપ્રિન્ટ ધરાવે છે, તેઓ ક્યારેય ચેલેન્જ ટ્રિગર કરતા નથી, તેથી જ્યારે સાચો વપરાશકર્તા સાઇટ પર આવે ત્યાં સુધી સમસ્યા અદ્રશ્ય રહે છે.
લોગ્સમાં શું જાણવા મળ્યું
વપરાશકર્તાના Chrome સત્રના લાઈવ નેટવર્ક ટ્રેસથી એક જ એન્ડપોઇન્ટ પર બે વિરોધાભાસી રિક્વેસ્ટ જોવા મળી:
- Navigation POST → 503 રિસ્પોન્સ, ટેબ હેંગ થઈ ગયું.
- fetch() POST → રિક્વેસ્ટ પૂર્ણ થઈ.
બંને રિક્વેસ્ટ એક જ ઓરિજિનમાંથી આવી હતી, સમાન ક્રેડેન્શિયલ્સ ધરાવતી હતી અને એક જ સમયે બની હતી. એકમાત્ર તફાવત ટ્રાન્સપોર્ટ પદ્ધતિનો હતો. fetch રિક્વેસ્ટે ઇન્ટરસ્ટીશિયલ ફ્લોને બાયપાસ કરી દીધો જે નેવિગેશન POSTs ને બ્લોક કરે છે.
નિષ્ફળતા તરફ દોરી જનારા રસ્તાઓ
ડેવલપરે મૂળ કારણને ચૂકી જતી અનેક સુધારાના પ્રયાસો કર્યા:
- Turnstile ટોકન્સ રીન્યુ કર્યા, એવું માનીને કે તેઓ એક્સપાયર થઈ ગયા હતા.
- IP રેન્જને વ્હાઇટલિસ્ટ કરી, એવું વિચારીને કે બ્લોક લોકેશન-આધારિત હતો.
- એક્સટેન્શન ડિસેબલ કર્યા, સર્વિસ વર્કર્સ ક્લિયર કર્યા અને કૂકીઝ ડિલીટ કરી.
દરેક ફેરફાર પછી પણ ભૂલ યથાવત રહી કારણ કે નિષ્ફળતા ક્લાયન્ટ અથવા સર્વર કોડમાં નહીં, પરંતુ અપસ્ટ્રીમ એજ (edge) પરથી ઉદ્ભવી હતી.
વ્યવહારુ ઉકેલ
Cloudflare ના રક્ષણને બંધ કરવાને બદલે, ફોર્મને fetch-first પેટર્નનો ઉપયોગ કરવા માટે ફરીથી એન્જિનિયર કરવામાં આવ્યું હતું:
- ફોર્મ ડેટા એકત્રિત કરો અને તેને
fetch()સાથે JSON પેલોડ તરીકે મોકલો. - સર્વરના રિસ્પોન્સને હેન્ડલ કરો. જો સર્વર પેમેન્ટ ગેટવે માટે URL રિટર્ન કરે છે, તો સાદા GET રિક્વેસ્ટ સાથે ત્યાં જવા માટે
location.assign()નો ઉપયોગ કરો.
Fetch રિક્વેસ્ટ ઇન્ટરસ્ટીશિયલ ચેલેન્જ ટ્રિગર કરતી નથી, તેથી POST ઓરિજિન સર્વર સુધી પહોંચે છે. ત્યારબાદનું GET રીડાયરેક્ટ સુરક્ષિત રીતે કોઈપણ ચેલેન્જમાંથી પસાર થઈ શકે છે, કારણ કે GET બોડીઝ ખાલી હોય છે અને વપરાશકર્તા ચેલેન્જ ક્લિયર કર્યા પછી તેને ફરીથી રન કરી શકાય છે.
ડેવલપર્સ માટે જોખમો
- વપરાશકર્તાનો વિશ્વાસ: જે પેમેન્ટ ફોર્મ શાંતિથી નિષ્ફળ જાય છે તે વિશ્વાસ ઘટાડે છે અને આવક ગુમાવવા તરફ દોરી શકે છે.
- મેન્ટેનન્સ ઓવરહેડ: આ ઘટના માટે ત્રણ પેચ રિલીઝ અને તપાસ માટે આખો દિવસ જોઈતો હતો.
- ટેસ્ટિંગ બ્લાઈન્ડ સ્પોટ્સ: માત્ર આંતરિક ટેસ્ટિંગ એન્વાયરમેન્ટ પર નિર્ભર રહેવાથી એવા એજ-કેસ નિષ્ફળતાઓ ચૂકી શકાય છે જે માત્ર વાસ્તવિક ઉપયોગમાં જ દેખાય છે.
વ્યાપક સમુદાય માટે પાઠ
- વાસ્તવિક બ્રાઉઝર્સના ડેટાનું નિરીક્ષણ કરો. જ્યારે સમસ્યા માત્ર વાસ્તવિક વપરાશકર્તાઓ માટે જ દેખાય, ત્યારે ઓટોમેટેડ ટેસ્ટ રન પર વિશ્વાસ કરવાને બદલે તે સત્રોના નેટવર્ક લોગ્સ કેપ્ચર કરો.
- એજ (edge) ને સ્ટેકના ભાગ તરીકે ગણો. Cloudflare ક્લાયન્ટ અને સર્વરની વચ્ચે છે; તેનું વર્તન રિક્વેસ્ટ કેવી રીતે સ્ટ્રક્ચર કરવી જોઈએ તેના પર અસર કરે છે.
- યોગ્ય ટ્રાન્સપોર્ટ પસંદ કરો. નેવિગેશન POSTs અને fetch POSTs એજ પર અલગ અલગ માર્ગો દ્વારા મુસાફરી કરે છે. એ જ તફાવતને ધ્યાનમાં રાખીને API ડિઝાઇન કરો.
- ભૂલની વિગતો જાહેર કરો. 503 અથવા “timeout-or-duplicate” મેસેજને UI પર બતાવો જેથી ડેવલપર્સ લોગ્સમાં ઊંડા ઉતર્યા વગર ચોક્કસ નિષ્ફળતા જોઈ શકે.
આગળ શું ધ્યાન રાખવું
ડેવલપર્સે કોઈપણ ફોર્મ-આધારિત વર્કફ્લોનું ઓડિટ કરવું જોઈએ જે નેટિવ POST નેવિગેશન પર આધારિત હોય, ખાસ કરીને જ્યારે Cloudflare અથવા સમાન CDN સુરક્ષા સેવાઓ સાઇટની આગળ હોય. હળવું (lightweight) fetch વ્રેપર ઉમેરવાથી સમાન નિષ્ફળતાઓ અટકાવી શકાય છે. એજ-જનરેટેડ સ્ટેટસ કોડ્સ કેપ્ચર કરતા મોનિટરિંગ ટૂલ્સ સમસ્યા ગ્રાહકો સુધી પહોંચે તે પહેલાં તેને ફ્લેગ કરી દેશે.
મુખ્ય મુદ્દો: જ્યારે Cloudflare ના બોટ ચેલેન્જિસ સક્રિય હોય, ત્યારે સાદું HTML ફોર્મ સબમિશન સાયલન્ટ ફેઈલ્યોર (silent failure) માટે સંવેદનશીલ હોય છે. fetch() દ્વારા POST ને રી-રૂટ કરીને અને GET રીડાયરેક્ટ સાથે ફ્લો પૂર્ણ કરીને, સુરક્ષાને અકબંધ રાખીને એજ (edge) ની મર્યાદાઓને ટાળી શકાય છે. એજને માત્ર નેટવર્ક હોપ તરીકે નહીં, પરંતુ કોડ તરીકે ગણો, અને તે મુજબ તમારા ટ્રાન્સપોર્ટ્સ ડિઝાઇન કરો.