Preflight अनुरोध क्या है? CORS जाँच समझाई गई

Scrapeless Agent Browser ऐसे ब्राउज़र-आधारित वर्कफ़्लो चलाता है जिनमें लक्षित पृष्ठ ब्राउज़र के cross-origin अनुरोध नियमों के अधीन रहते हैं।

सारांश

CORS preflight किसी प्रस्तावित cross-origin अनुरोध के लिए अनुमति की जाँच करता है। ब्राउज़र कुछ एप्लिकेशन अनुरोधों से पहले एक OPTIONS अनुरोध भेजता है।
केवल सफल OPTIONS स्थिति पर्याप्त नहीं है। ब्राउज़र को प्रस्तावित ऑपरेशन के विरुद्ध आवश्यक CORS फ़ील्ड्स का सत्यापन करना होता है।
CORS अनुमति API authorization की जगह नहीं लेती। रिसोर्स सर्वर अब भी क्रेडेंशियल और ऑपरेशन अनुमतियाँ जाँचता है।
Command-line पर सफलता ब्राउज़र एक्सेस को सिद्ध नहीं करती। ब्राउज़र origin नीति ऐसे जाँच जोड़ती है जिन्हें सर्वर-साइड HTTP क्लाइंट लागू नहीं करता।

Preflight एक प्रस्तावित ब्राउज़र अनुरोध के बारे में पूछता है

CORS preflight एक HTTP OPTIONS अनुरोध होता है जिसे ब्राउज़र यह जाँचने के लिए भेजता है कि क्या सर्वर किसी विशेष cross-origin अनुरोध की अनुमति देता है। यह कॉल करने वाले origin, प्रयोजित method, और संबंधित request-field नामों का वर्णन करता है। यदि सर्वर की प्रतिक्रिया ब्राउज़र की जाँचों को संतुष्ट करती है, तो ब्राउज़र एप्लिकेशन अनुरोध के साथ आगे बढ़ सकता है। Preflight ब्राउज़र के access मॉडल में अनुमति-समझौता होता है, न कि स्वयं एप्लिकेशन ऑपरेशन।

the Fetch Standard CORS model इस व्यवहार को परिभाषित करता है। Origin scheme, host और port से निर्धारित होता है, इसलिए दो URLs अलग origins के हो सकते हैं, भले ही उनके डोमेन बहुत समान दिखें। एक origin से परोसा गया frontend और दूसरे origin से परोसा गया API, ब्राउज़र JavaScript द्वारा API प्रतिक्रिया तक पहुँचने के लिए CORS कॉन्फ़िगरेशन की आवश्यकता रख सकते हैं।

CORS का अर्थ Cross-Origin Resource Sharing है। यह किसी सर्वर को same-origin सुरक्षा मॉडल के भीतर कुछ cross-origin ब्राउज़र इंटरैक्शन स्वीकार करने की अनुमति देता है। नीति ब्राउज़र द्वारा लागू की जाती है, जबकि सर्वर प्रतिक्रिया फ़ील्ड्स के माध्यम से यह घोषित करता है कि वह क्या अनुमति देता है। कोई एप्लिकेशन अस्वीकृत cross-origin अनुरोध को अपनी outgoing request में response-permission फ़ील्ड जोड़ कर हल नहीं कर सकता।

हर cross-origin अनुरोध पर preflight नहीं होता

कुछ cross-origin अनुरोध CORS-safelisted method और field नियमों के भीतर आते हैं और उन्हें preflight की आवश्यकता नहीं होती। सटीक शर्तों में method, request-field मान और संबंधित Fetch व्यवहार शामिल होते हैं। किसी गैर-safelisted field के साथ एक GET को preflight की आवश्यकता हो सकती है, जबकि उपयुक्त रूप से सीमित POST इससे बच सकता है। इसलिए केवल method नाम निर्णय के लिए अधूरा नियम है।

आम ट्रिगर्स में safelisted सेट के बाहर के methods, Authorization field, और ऐसा JSON content type शामिल हैं जो safelisted media types में नहीं आता। ये उदाहरण कई ब्राउज़र नेटवर्क ट्रेस समझाते हैं, लेकिन पूरा परीक्षण Fetch नियमों का है। सभी GETs को simple या सभी POSTs को preflighted बताने से बचें। वास्तविक अनुरोध कॉन्फ़िगरेशन की जाँच करें।

the browser preflight request explanation प्रारंभिक OPTIONS अनुरोध को वास्तविक अनुरोध से अलग दर्शाती है। कोई सर्वर ऐसे अनुरोध प्राप्त कर सकता है जिन्हें preflight की आवश्यकता नहीं, जबकि ब्राउज़र अब भी उनकी responses को JavaScript के सामने प्रकट करने से इंकार कर सकता है। इसलिए CORS को ऐसा सार्वभौमिक अवरोधक नहीं बताना चाहिए जो हर cross-origin अनुरोध को सर्वर तक पहुँचने से रोक देता हो।

ब्राउज़र प्रयोजित method और fields का वर्णन करता है

Preflight में Origin शामिल होता है, जो कॉल करने वाले origin की पहचान करता है। Access-Control-Request-Method वह method नामित करता है जिसका उपयोग ब्राउज़र वास्तविक अनुरोध के लिए करने का प्रस्ताव रखता है। Access-Control-Request-Headers उन संबंधित request-field नामों को सूचीबद्ध करता है जिन्हें अनुमति की आवश्यकता है। ये किसी प्रस्तावित ऑपरेशन के वर्णन हैं; इनका अर्थ यह नहीं कि स्वयं OPTIONS अनुरोध वह ऑपरेशन करता है या एप्लिकेशन का पूरा payload लेकर चलता है।

सर्वर, लागू होने पर, अनुमत origins, methods और request fields का वर्णन करने वाले फ़ील्ड्स के साथ प्रतिक्रिया देता है। ब्राउज़र उन घोषणाओं का प्रस्तावित अनुरोध के विरुद्ध मूल्यांकन करता है। एक सामान्य सफल OPTIONS handler तब अपर्याप्त है जब वह आवश्यक अनुमति छोड़ देता है या कोई भिन्न method प्रदान करता है। तुलना को सटीक रखें ताकि निदान बता सके कि नीति का कौन-सा भाग विफल हुआ।

Field	Direction	अदला-बदली में अर्थ
Origin	ब्राउज़र अनुरोध	कॉल करने वाले पृष्ठ का origin
Access-Control-Request-Method	Preflight अनुरोध	एप्लिकेशन अनुरोध के लिए प्रस्तावित method
Access-Control-Request-Headers	Preflight अनुरोध	अनुमति आवश्यक request-field नाम
Access-Control-Allow-Origin	सर्वर प्रतिक्रिया	वह origin access जिसे सर्वर अनुमति देता है
Access-Control-Allow-Methods	Preflight प्रतिक्रिया	अनुमत request methods
Access-Control-Allow-Headers	Preflight प्रतिक्रिया	अनुमत request-field नाम
Access-Control-Max-Age	प्रीफ्लाइट प्रतिक्रिया	प्रीफ्लाइट परिणाम को कैश करने के लिए अनुमत अवधि

एक एप्लिकेशन अनुरोध एक अलग एक्सचेंज बना रहता है। एक बार जब यह पहुंच जाता है, तो API उसके क्रेडेंशियल्स, पैरामीटर और अनुमतियों को मान्य करता है। इसकी प्रतिक्रिया को भी ब्राउज़र एक्सेस के लिए उपयुक्त CORS फ़ील्ड की आवश्यकता होती है। प्रारंभिक जांच पास कर लेना किसी बाद की अनधिकृत या गलत रूप से निर्मित एप्लिकेशन ऑपरेशन को सफल नहीं बनाता, और यह वास्तविक प्रतिक्रिया को origin-policy हैंडलिंग से मुक्त नहीं करता।

क्रेडेंशियल्स मूल (Origin) कॉन्फ़िगरेशन को अधिक विशिष्ट बनाते हैं

क्रेडेंशियल्स वाले ब्राउज़र अनुरोधों के लिए CORS प्रतिक्रिया नीति का क्रेडेंशियल मोड और अनुरोध करने वाले origin से मेल खाना आवश्यक है। क्रेडेंशियल्ड प्रतिक्रिया को उजागर करते समय वाइल्डकार्ड अनुमत origin को किसी स्पष्ट origin के सामान्य विकल्प के रूप में उपयोग नहीं किया जा सकता। सर्वर को उपयुक्त क्रेडेंशियल अनुमति की भी आवश्यकता होती है। इन फ़ील्डों को बिना जांचे मनमाने इनपुट को प्रतिबिंबित करने के बजाय नियंत्रित origin नीति से कॉन्फ़िगर करें।

कुकीज़ CORS से परे अतिरिक्त नियम पेश करती हैं। कोई अनुरोध अपनी CORS नीति को संतुष्ट कर सकता है जबकि कुकी डिलीवरी कुकी विशेषताओं या ब्राउज़र गोपनीयता व्यवहार द्वारा सीमित होती है। इसके विपरीत, कुकी की उपस्थिति यह स्थापित नहीं करती कि सर्वर ने सत्र स्वीकार कर लिया। कुकी डिलीवरी, CORS एक्सपोज़र और एप्लिकेशन ऑथराइज़ेशन को अलग-अलग डायग्नोस्टिक प्रश्नों के रूप में रखें।

The CORS क्रेडेंशियल और प्रतिक्रिया-फ़ील्ड संबंधी मार्गदर्शन इन इंटरैक्शन को कवर करता है। मानक मॉडल के तहत एक प्रीफ्लाइट आम तौर पर क्रेडेंशियल्स को बाहर रखता है, भले ही प्रस्तावित एप्लिकेशन अनुरोध क्रेडेंशियल्ड हो। ऐसा मिडलवेयर जो हर OPTIONS अनुरोध के लिए लॉग-इन सत्र की आवश्यकता रखता है, अधिकृत एप्लिकेशन अनुरोध का मूल्यांकन होने से पहले ही वार्तालाप (नेगोशिएशन) को अवरुद्ध कर सकता है।

असफल प्रीफ्लाइट और असफल API कॉल अलग-अलग होते हैं

एक असफल प्रीफ्लाइट ब्राउज़र को प्रस्तावित एप्लिकेशन अनुरोध भेजने से रोक सकता है। उस स्थिति में API रूट के लॉग में संबंधित एप्लिकेशन ऑपरेशन न हो, जबकि गेटवे OPTIONS दर्ज करता है। निदान की शुरुआत यह निर्धारित करके करें कि कौन सा एक्सचेंज हुआ था। कंसोल में एक सामान्य CORS त्रुटि अपने आप में यह पहचान नहीं करती कि रूटिंग, फ़ील्ड नीति, क्रेडेंशियल्स या वास्तविक प्रतिक्रिया ने समस्या उत्पन्न की।

यदि एप्लिकेशन अनुरोध वास्तव में सर्वर तक पहुंच गया था, तो उसके अपने स्टेटस और CORS प्रतिक्रिया फ़ील्ड की जांच करें। कोई सेवा ऐसा उपयोगी त्रुटि बॉडी लौटा सकती है जिसे ब्राउज़र JavaScript नहीं पढ़ सकता क्योंकि त्रुटि प्रतिक्रिया ने origin अनुमति छोड़ दी। सामान्य API ऑथराइज़ेशन को बनाए रखते हुए इच्छित CORS नीति को समर्थित सफल और त्रुटि प्रतिक्रियाओं पर समान रूप से लागू करें। हर असफलता को origin allowlist परिवर्तन में न बदलें।

एक OPTIONS अनुरोध हमेशा CORS प्रीफ्लाइट नहीं होता। HTTP OPTIONS को अधिक सामान्य रूप से लक्षित संसाधन के लिए संचार विकल्पों के बारे में एक अनुरोध के रूप में परिभाषित करता है। HTTP OPTIONS semantics और CORS अनुरोध फ़ील्ड की उपस्थिति ब्राउज़र प्रीफ्लाइट को मैन्युअल रूप से जारी किए गए OPTIONS अनुरोध या किसी अन्य इन्फ्रास्ट्रक्चर जांच से अलग पहचानने में मदद करती है। केवल उसके method नाम के आधार पर नहीं, बल्कि वास्तव में मौजूद अनुरोध का निदान करें।

प्रीफ्लाइट कैशिंग का अपना लाइफ़साइकल होता है

ब्राउज़र लागू नियमों के अनुसार, जिनमें Access-Control-Max-Age और इम्प्लिमेंटेशन सीमाएँ शामिल हैं, सफल प्रीफ्लाइट अनुमति को कैश कर सकते हैं। वह कैश साधारण कैश की गई एप्लिकेशन प्रतिक्रिया सामग्री से अलग होता है। यह समझा सकता है कि बाद में कोई अनुरोध नया OPTIONS एक्सचेंज किए बिना क्यों दिखाई देता है। एक ट्रेस में प्रीफ्लाइट की अनुपस्थिति यह साबित नहीं करती कि अनुरोध को कभी इसकी आवश्यकता नहीं होगी।

कैशिंग स्कोप भी अनुरोध संदर्भ, origin, लक्ष्य, method और फ़ील्ड अनुमतियों पर निर्भर करता है। किसी एक रूट या फ़ील्ड सेट के लिए सफल जांच होस्ट पर हर ऑपरेशन के लिए समग्र (ब्लैंकेट) अनुमति नहीं होती। डिबग करते समय, प्रस्तावित method और अनुरोध फ़ील्ड को लक्ष्य URL के साथ रिकॉर्ड करें। इन विवरणों के बिना ट्रेस की तुलना करना सामान्य नीति अंतर को असंगत जैसा दिखा सकता है।

जो सर्वर अलग-अलग कॉलर के लिए अलग origin अनुमतियाँ लौटाता है, उसे मध्यवर्ती कैश व्यवहार का ध्यान रखना चाहिए। HTTP कैश चयन नियम समझाते हैं कि अनुचित पुन: उपयोग को रोकने के लिए प्रतिक्रिया भिन्नता को कैसे दर्शाया जाना चाहिए। जहां कोई एप्लिकेशन प्रतिक्रिया Origin के आधार पर बदलती है, वहाँ किसी एक कॉलर के origin डिक्लेरेशन को दूसरे के लिए अंधाधुंध पुन: उपयोग करने देने के बजाय संबंधित कैश variation कॉन्फ़िगर करें।

Origin से एप्लिकेशन तक एक्सचेंज को डिबग करें

कॉलिंग पेज के पूर्ण origin और अंतिम API लक्ष्य से शुरू करें। जांचें कि क्या कोई redirect या गेटवे OPTIONS को एप्लिकेशन method से अलग तरह से रूट करता है। प्रस्तावित method और फ़ील्ड की तुलना सर्वर की स्पष्ट नीति से करें। फिर देखें कि वास्तविक अनुरोध पहुंचा या नहीं और क्या उसकी प्रतिक्रिया में अपेक्षित CORS फ़ील्ड शामिल हैं। यह अनुक्रम बिना नीति को अंधाधुंध कमजोर किए विफलता का पता लगाता है।

कमान्ड-लाइन क्लाइंट HTTP प्रतिक्रिया का निरीक्षण करने में मदद कर सकता है, लेकिन यह अपने आप ब्राउज़र CORS प्रवर्तन को दोहराता नहीं है। किसी अनुरोध का बैकएंड प्रक्रिया से सफल होना केवल यह साबित करता है कि इस प्रक्रिया ने अपने स्वयं के नेटवर्क और क्रेडेंशियल संदर्भ के तहत प्रतिक्रिया प्राप्त की। ब्राउज़र अभी भी origin नियमों का मूल्यांकन करता है। क्लाइंट को ऐसे मोड में बदल देना जो प्रतिक्रिया को छुपाता है, संरक्षित प्रतिक्रिया सामग्री को पढ़ने की अनुमति उत्पन्न नहीं करता।

डायग्नोस्टिक को स्वच्छ (sanitized) रखें। ऑथराइज़ेशन मान और कुकीज़ को साझा ट्रेस में पेस्ट नहीं करना चाहिए। आम तौर पर केवल फ़ील्ड नाम, origin, रूट, method, स्टेटस और अनुमति-फ़ील्ड के मान CORS मिसमैच समझाने के लिए पर्याप्त होते हैं। यदि एप्लिकेशन व्यक्तिगत रिकॉर्ड को छूता है, तो अधिकृत जांच के लिए केवल न्यूनतम आवश्यक सामग्री को कैप्चर करें और उस कैप्चर को उपयुक्त एक्सेस सीमा के भीतर रखें।

ब्राउज़र ऑटोमेशन अभी भी origin मॉडल का पालन करता है

Scrapeless Agent Browser स्वचालित नेविगेशन और इंटरैक्शन के लिए ब्राउज़र वातावरण प्रदान करता है। यह लक्षित पेज के cross-origin एप्लिकेशन कॉन्ट्रैक्ट को नहीं बदलता। Agent Browser overview ब्राउज़र की क्षमता का वर्णन करता है, जबकि पेज और API मालिक मूल नीति और कॉलर को दिए गए अनुमतियों के लिए जिम्मेदार रहते हैं।

ब्राउज़र कंट्रोल कनेक्शन को लक्ष्य पेज के अंदर चल रहे JavaScript से अलग रखें। क्लाउड ब्राउज़र तक पहुँचता ऑटोमेशन क्लाइंट और क्रॉस-ओरिजिन API तक पहुँचती पेज स्क्रिप्ट अलग नेटवर्क इंटरेक्शन हैं। कंट्रोल चैनल में सफलता यह साबित नहीं कर सकती कि पेज की API कॉल ने CORS पास कर लिया। यह समझाते समय कि पेज क्या एक्सेस कर सका, लक्ष्य अनुरोध और उसके संबंधित प्रतिक्रिया का अवलोकन करें।

The Fetch अनुरोध वर्कफ़्लो HTTP क्लाइंट्स के लिए संबंधित पाठ है, और Scrapeless pricing ब्राउज़र सेवा उपयोग को कवर करता है। एक अधिकृत परीक्षण के लिए, अपेक्षित origin, operation, और दृश्य पेज परिणाम को परिभाषित करें। एक सफल ब्राउज़र अवलोकन को केवल OPTIONS स्टेटस पर रुकने की बजाय, नीति विनिमय और परिणामस्वरूप एप्लिकेशन व्यवहार दोनों की पुष्टि करनी चाहिए।

निष्कर्ष

कुछ ब्राउज़र अनुरोधों के आगे बढ़ने से पहले, प्रीफ़्लाइट एक विशिष्ट प्रस्तावित क्रॉस-ओरिजिन ऑपरेशन का मूल्यांकन करता है। कॉलिंग origin, method, field नाम, credential मोड, और दोनों प्रतिक्रियाओं का निरीक्षण करें। ब्राउज़र अनुमति जांचों को API authorization से अलग रखें, और विफल विनिमय के मालिक कंपोनेंट पर नीति का निदान करें।

अपना वेब डेटा वर्कफ़्लो बनाएँ

Agent Browser का उपयोग करें ताकि अनुमत पेज वर्कफ़्लो का अवलोकन कर सकें और वास्तविक लक्ष्य अनुरोध सीमा पर क्रॉस-ओरिजिन व्यवहार की पुष्टि कर सकें।

आज ही साइन अप करें और प्राप्त करें $5 in free credit — कोई क्रेडिट कार्ड आवश्यक नहीं.

अपना $5 क्रेडिट क्लेम करें →

FAQ

क्या हर क्रॉस-ओरिजिन अनुरोध को प्रीफ़्लाइट की ज़रूरत होती है?

हर क्रॉस-ओरिजिन अनुरोध को प्रीफ़्लाइट की ज़रूरत नहीं होती। ब्राउज़र method, अनुरोध फ़ील्ड, उनके मान, और लागू Fetch नियमों का मूल्यांकन करता है। बिना प्रीफ़्लाइट वाला अनुरोध भी अपने क्रॉस-ओरिजिन response तक JavaScript की पहुँच के लिए उपयुक्त CORS response अनुमति की माँग करता है।

क्या OPTIONS पर HTTP 200 यह साबित करता है कि CORS सही है?

OPTIONS पर HTTP 200 यह साबित नहीं करता कि CORS सही है। ब्राउज़र अनुमत origin, method, फ़ील्ड, और credential आवश्यकताओं की भी जाँच करता है। प्रारंभिक विनिमय के सफल होने के बाद वास्तविक एप्लिकेशन प्रतिक्रिया को अपनी स्वयं की CORS जांचों को संतुष्ट करना चाहिए।

क्या CORS एक authentication सिस्टम है?

CORS एक authentication सिस्टम नहीं है। यह ब्राउज़र कोड द्वारा क्रॉस-ओरिजिन एक्सेस को नियंत्रित करता है। API को क्रेडेंशियल्स को अलग से मान्य करना और संसाधन अनुमतियों को लागू करना होता है, उन क्लाइंट्स सहित जो ब्राउज़र origin-policy जांचों को लागू नहीं करते।

एक API बैकएंड से काम क्यों करता है लेकिन ब्राउज़र में विफल हो जाता है?

एक API बैकएंड से काम कर सकता है जबकि ब्राउज़र में विफल हो सकता है क्योंकि ब्राउज़र JavaScript को same-origin और CORS नियमों को संतुष्ट करना पड़ता है। क्रेडेंशियल्स, अंतिम URLs, और अनुरोध फ़ील्ड्स की भी तुलना करें; दोनों क्लाइंट संभव है समान अनुरोध न भेज रहे हों।

बाद के नेटवर्क ट्रेस में OPTIONS अनुरोध क्यों नहीं है?

एक बाद का ट्रेस OPTIONS को छोड़ सकता है क्योंकि या तो अनुरोध को प्रीफ़्लाइट की आवश्यकता नहीं है या वैध प्रीफ़्लाइट अनुमति पहले से कैश है। निष्कर्ष निकालने से पहले पूर्ण अनुरोध संदर्भ की तुलना करें। एप्लिकेशन-रेस्पॉन्स कैशिंग और प्रीफ़्लाइट परमिशन कैशिंग अलग तंत्र हैं।