प्रेफ्लाइट अनुरोध क्या है? CORS OPTIONS जांचें समझाया

प्रेफ्लाइट अनुरोध क्या है?

एक प्रेफ्लाइट अनुरोध एक स्वचालित CORS जांच है जिसमें एक ब्राउज़र कुछ क्रॉस-उरजन अनुरोधों से पहले OPTIONS अनुरोध भेजता है। प्रेफ्लाइट कॉलर की उत्पत्ति, नियोजित विधि, और गैर-सुरक्षित अनुरोध फ़ील्ड नामों की पहचान करता है। सर्वर की प्रतिक्रिया ब्राउज़र को बताती है कि क्या वह वास्तविक अनुरोध भेज सकता है; प्रेफ्लाइट उस नियोजित अनुप्रयोग संचालन को निष्पादित नहीं करता है।

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

API डेवलपर्स के लिए, पहला प्रश्न यह है कि मान या व्यवहार कौन बनाता है। अगला प्रश्न यह है कि इसे कौन व्याख्या करता है। अंतिम प्रश्न यह है कि कौन सा प्रेक्षित परिणाम यह साबित करता है कि व्याख्या सफल रही। उन तीन उत्तरों से एक शब्दावली शब्द एक परीक्षण योग्य इंटरफ़ेस अनुबंध में बदल जाती है।

वास्तविक अनुरोध से पहले OPTIONS जांचें

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

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

सर्वर या गेटवे एक्सेस-नियंत्रण-अनुमति-उत्पत्ति के साथ विधि और फ़ील्ड अनुमतियों को लौटाता है जो नियोजित विनिमय को कवर करता है। यह एक्सेस-नियंत्रण-मैक्स-एज भी लौटा सकता है ताकि ब्राउज़र सफल प्रेफ्लाइट परिणाम को कार्यान्वयन सीमाओं के भीतर कैश कर सके।

केवल नीति के मेल खाने के बाद ब्राउज़र वास्तविक अनुरोध भेजता है। उस दूसरे प्रतिक्रिया में भी उचित CORS अनुमति होनी चाहिए। OPTIONS पास करते हुए लेकिन वास्तविक प्रतिक्रिया पर फ़ील्ड को छोड़ देना अभी भी एक ब्राउज़र-दृश्यमान विफलता पैदा करता है।

एक प्रेफ्लाइट जोड़ी को पढ़ना

निम्नलिखित शर्तें उन अवयवों को अलग करती हैं जो अक्सर एक लेबल में समाहित होती हैं। उन्हें प्रतिभागियों के बीच इंटरफेस के रूप में पढ़ें न कि नेटवर्क ट्रेस में सजावट के रूप में।

वेब डेटा संग्रह में प्रेफ्लाइट अनुरोध का महत्व क्यों है

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

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

सत्र निरंतरता तब महत्वपूर्ण होती है जब एक प्रतिक्रिया अगले अनुरोध के लिए स्थिति स्थापित करती है। एक अधिकृत अनुक्रम को एक सीमित ग्राहक संदर्भ के भीतर बनाए रखें, आवश्यक स्थानीयता और नेटवर्क उत्पत्ति को संरक्षित करें, और अप्रासंगिक कार्यों से स्थिति को मिलाने से बचें। एक प्रॉक्सी नेटवर्क उत्पत्ति को बदलता है; यह हेडर को पुनरुत्पादित नहीं करता है, प्रतिनिधित्व को डिकोड नहीं करता है, स्क्रिप्ट को निष्पादित नहीं करता है, या प्रतिबंधित सामग्री तक पहुंच प्रदान नहीं करता।

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

मध्यस्थों को स्पष्ट ध्यान देने की आवश्यकता है। एक सामग्री वितरण नेटवर्क एक एन्कोडेड संस्करण का चयन कर सकता है, एक गेटवे विकल्पों का उत्तर दे सकता है, एक कैश एक बातचीत की गई प्रतिक्रिया का पुनः उपयोग कर सकता है, और एक अनुप्रयोग सर्वर कुकीज़ या प्राधिकरण क्षेत्रों को सेट कर सकता है। केवल अनुप्रयोग कोड की तुलना अंतिम पृष्ठ आउटपुट से करना उस परत को छोड़ देता है जिसने संभवतः निर्णय लिया था।

स्क्रेपलेस यूनिवर्सल स्क्रैपिंग API तब प्रासंगिक है जब एक टीम को अनुमत सार्वजनिक सामग्री की प्रबंधित पुनः प्राप्ति की आवश्यकता होती है, जिसमें JavaScript-रेन्डर्ड पृष्ठ शामिल हैं। अधिग्रहण अनुबंध को अब भी लक्ष्य, अनुमत क्षेत्र, अपेक्षित प्रतिनिधित्व, स्वीकृति मार्कर और रोकने की शर्तों को परिभाषित करना चाहिए। उत्पाद क्षमता स्रोत शर्तों, गोपनीयता समीक्षा, या अनुप्रयोग-स्तरीय मान्यता को प्रतिस्थापित नहीं करती है।

अनुरोध जो आमतौर पर पुनः उड़ान को ट्रिगर करते हैं

पुनः उड़ान अनुरोध एक वास्तुकला में एक स्थान अर्जित करता है जब यह किसी ठोस उत्पाद व्यवहार, संगतता आवश्यकता, या निदान निर्णय को बदलता है। ये उपयोग मामलों में नौकरी को पहले और प्रोटोकॉल सुविधा को दूसरे बताने का विवरण होता है।

पुनः उड़ान और CORS-सुरक्षित अनुरोध

पुनः उड़ान अनुरोध HTTP की एक परत से संबंधित है और इसे निकटवर्ती परतों के साथ混淆 नहीं करना चाहिए। एक मजबूत कार्यान्वयन पहचानता है कि कौन सा घटक मान को चयनित करता है, कौन सा घटक इसे बदल सकता है, और अंतिम प्रतिनिधित्व सही होने का क्या प्रमाण है।

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

क्यों पुनः उड़ान हैंडलिंग टूटती है

• कोई हैंडलर नहीं है तो विकल्पों को रूट करना। गेटवे और ढाँचे एक सामान्य त्रुटि लौटा सकते हैं इससे पहले कि अनुप्रयोग CORS तर्क चले।
• विधि की अनुमति देते हुए, लेकिन क्षेत्र की नहीं। योजना बनाई गई विधि और हर अनुरोधित गैर-सुरक्षित सूची क्षेत्र को कवर किया जाना चाहिए।
• विकल्पों पर सामान्य क्रेडेंशियल की आवश्यकता। फेच पुनः उड़ान व्यवहार सामान्य अनुरोध क्रेडेंशियल को शामिल नहीं करता है।
• वास्तविक प्रतिक्रिया को भूलना। अनुमति जांच और बाद की प्रतिक्रिया के लिए लागू मूल नीति की आवश्यकता होती है।
• सिर्फ सर्वर एप्लिकेशन लॉग का डिबग करना। एक CDN, प्रॉक्सी, या वेब सर्वर एप्लिकेशन के देखने से पहले OPTIONS का उत्तर दे सकता है।
• एक आवश्यक अनुरोध क्षेत्र को अक्षम करना। प्रेफ्लाइट से बचने के लिए सुरक्षा या सामग्री क्षेत्रों को हटाना API अनुबंध को नुकसान पहुंचा सकता है।

ज़्यादातर विफलताएँ तब आसान हो जाती हैं जब आप यह मान लेना बंद कर देते हैं कि एक पुस्तकालय या ब्राउज़र ने स्वचालित रूप से क्या किया। एक न्यूनतम ट्रेस कैप्चर करें, गोपनीयताओं को हटाएं, और एक नियंत्रित चर को एक समय में बदलें। लक्ष्य लौटाए गए प्रतिनिधित्व का एक स्थिर स्पष्टीकरण है, न कि असंबंधित हेडर सुधारों का संग्रह।

एक प्रेफ्लाइट विफलता चेकलिस्ट

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

1. पृष्ठ के मूल, लक्षित मूल, नियोजित विधि, सामग्री प्रकार, और लेखक-नियंत्रित क्षेत्रों की पहचान करें।
2. OPTIONS एक्सचेंज खोलें और बिना यह मान लिए कि एप्लिकेशन ने इसे संभाला, इसकी स्थिति और प्रतिक्रिया क्षेत्रों को पढ़ें।
3. Access-Control-Allow-Origin को क्रेडेंशियल नियमों के तहत अनुरोध मूल के साथ मेल करें।
4. पुष्टि करें कि Access-Control-Allow-Methods नियोजित विधि को शामिल करता है।
5. पुष्टि करें कि Access-Control-Allow-Headers हर अनुरोधित गैर-सुरक्षित नाम क्षेत्र को कवर करता है।
6. CORS क्षेत्रों को अनदेखा करने वाले प्रतिक्रियाओं के लिए रीडायरेक्ट, प्रॉक्सी, और त्रुटि हैंडलरों की जांच करें।
7. OPTIONS पास होने के बाद, वास्तविक अनुरोध और प्रतिक्रिया का अलग एक्सचेंज के रूप में निरीक्षण करें।

समीक्षा समाप्त करें एक छोटा स्वीकार किए गए नमूने और एक अस्वीकृत नमूने को एक ही संपादन नियमों के साथ बचाकर। भविष्य के परिवर्तन ज्ञात पृष्ठ पहचान, अपेक्षित क्षेत्रों, और डिकोड की गई सामग्री के खिलाफ तुलना की जा सकती है न कि केवल मेमोरी या स्क्रीनशॉट के खिलाफ।

प्रेफ्लाइट अनुरोध के लिए सुरक्षा और अवलोकनशीलता

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

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

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

प्रेफ्लाइट अनुरोध को परिभाषित करने वाले मानक

फेच मानक प्रेफ्लाइट एल्गोरिदम ब्राउज़र की नीति जांच को परिभाषित करता है। यह प्राथमिक स्रोत इस लेख में उपयोग की जाने वाली शब्दावली और सीमा को ठीक करता है, जबकि कार्यान्वयन व्यवहार अभी भी चयनित क्लाइंट और तैनाती में देखा जाना है।

MDN की प्रेफ्लाइट अनुरोध शब्दावली OPTIONS अनुरोध क्षेत्रों को दिखाता है। यह प्राथमिक स्रोत इस लेख में उपयोग की जाने वाली शब्दावली और सीमा को ठीक करता है, जबकि कार्यान्वयन व्यवहार अभी भी चयनित क्लाइंट और तैनाती में देखा जाना है।

MDN का CORS गाइड प्रेफ्लाइट और क्रेडेंशियल सीमाओं को बताता है। यह प्राथमिक स्रोत इस लेख में उपयोग की जाने वाली शब्दावली और सीमा को ठीक करता है, जबकि कार्यान्वयन व्यवहार अभी भी चयनित क्लाइंट और तैनाती में देखा जाना है।

HTTP OPTIONS अर्थशास्त्र मूल HTTP विधि को परिभाषित करता है। यह प्राथमिक स्रोत इस लेख में उपयोग की जाने वाली शब्दावली और सीमा को ठीक करता है, जबकि कार्यान्वयन व्यवहार अभी भी चयनित क्लाइंट और तैनाती में देखा जाना है।

प्रेफ्लाइट डिबगिंग नियम

प्रेफ्लाइट और वास्तविक अनुरोध को दो अलग-अलग HTTP एक्सचेंज के रूप में मानें, और प्रत्येक प्रतिक्रिया का उत्पादन करने वाली परत पर मूल, विधि, क्षेत्र, क्रेडेंशियल, गेटवे, और अंतिम-प्रतिक्रिया व्यवहार की पुष्टि करें।

उस नियम को एक स्वीकृति परीक्षण में डालें। यह बताएं कि कौन सा प्रतिभागी संकेत भेजता है, कौन सा प्रतिभागी इसे व्याख्या करता है, कौन सा मध्यस्थ पथ को बदल सकता है, और कौन सा सामग्री मार्कर सफलता को साबित करता है। यह प्रेफ्लाइट अनुरोध को एक अवलोकनीय प्रणाली का हिस्सा बनाता है न कि एक लेबल जो किसी विफलता के बाद संलग्न होता है।

संदर्भ

• स्क्रैपलेस यूनिवर्सल स्क्रैपिंग एपीआई दस्तावेज़
• स्क्रैपलेस यूनिवर्सल स्क्रैपिंग एपीआई उत्पाद अवलोकन
• स्क्रैपलेस हेडर, कुकीज़, सत्रों और प्रतिनिधित्व मान्यता के लिए मार्गदर्शिका
• स्क्रैपलेस गिटहब पर