CORS क्या है? ब्राउज़र क्रॉस-ओरिजिन एक्सेस समझाया गया

CORS क्या है?

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

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

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

ब्राउज़र CORS निर्णय कैसे बनाता है

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

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

ब्राउज़र प्रतिक्रिया को अनुरोध संदर्भ के साथ तुलना करता है। यदि नीति मेल नहीं खाती है, तो स्क्रिप्ट सुरक्षित प्रतिक्रिया को पढ़ने से रोका गया है जबकि सर्वर ने HTTP अनुरोध को संसाधित किया हो सकता है। यह अंतर समझाता है कि कंसोल में CORS त्रुटि क्यों दिखाई देती है जबकि सर्वर लॉग में एक आने वाले अनुरोध को दिखाया जाता है।

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

CORS फ़ील्ड जो अनुमति को परिभाषित करते हैं

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

क्यों CORS वेब डेटा संग्रह में महत्वपूर्ण है

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

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

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

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

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

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

वास्तविक उत्पादों से मेल खाने वाली CORS कॉन्फ़िगरेशन

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

CORS, समान-मूल नीति, CSRF, और प्रमाणीकरण

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

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

CORS गलत कॉन्फ़िगरेशन और गलत फ़िक्स

• प्रत्येक मूल को दर्शाते हुए। अमान्य किए गए इनपुट को प्रतिध्वनित करना हमलावर के मूल को ब्राउज़र पढ़ने की अनुमति दे सकता है।
• क्रेडेंशियल के साथ वाइल्डकार्ड का उपयोग करना। प्रमाणित ब्राउज़र अनुरोधों के लिए एक स्पष्ट रूप से अनुमति दी गई मूल की आवश्यकता होती है न कि वाइल्डकार्ड अनुमति।
• CORS को प्रमाणीकरण के रूप में मान लेना। CORS ब्राउज़र प्रतिक्रिया पहुँच को नियंत्रित करता है; सर्वर को अभी भी हर ऑपरेशन को प्रमाणीकरण और प्राधिकृत करना चाहिए।
• सिर्फ सफलता प्रतिक्रियाओं को हेडर जोड़ना। त्रुटियों और प्रीफ्लाइट प्रतिक्रियाओं के लिए भी नीति क्षेत्रों की आवश्यकता होती है ताकि ब्राउज़र उपयोगी निदान को उजागर कर सके।
• पहुंच को हल करने के लिए नो-कोर्स का उपयोग करना। परिणामी अपारदर्शी प्रतिक्रिया एक सामान्य पठनीय API प्रतिक्रिया नहीं है और गायब सर्वर की अनुमति नहीं देती है।
• कैश भिन्नता को भूलना। डायनेमिक उत्पत्ति प्रतिक्रियाएं कैशिंग व्यवहार में उत्पत्ति का ध्यान रखना चाहिए ताकि एक टेनेट की अनुमति दूसरी टेनेट को न मिले।

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

एक CORS निदान पृष्ठ से उत्पत्ति तक

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

1. पृष्ठ उत्पत्ति और लक्षित उत्पत्ति को योजना, होस्ट और पोर्ट के रूप में लिखें।
2. ब्राउज़र नेटवर्क पैनल की जांच करें यह निर्धारित करने के लिए कि क्या विफल आदान-प्रदान प्रीफ्लाइट या वास्तविक अनुरोध है।
3. उत्पत्ति अनुरोध क्षेत्र और प्रतिक्रिया में सटीक एक्सेस-नियंत्रण-इजाजत-उत्पत्ति मान की जांच करें।
4. प्रीफ्लाइट के लिए, अनुरोधित विधि और फ़ील्ड नामों की तुलना सर्वर की अनुमति सूची से करें।
5. क्रेडेंशियल के लिए, स्पष्ट उत्पत्ति अनुमति, क्रेडेंशियल अनुमति, कुकी नियम, और अनुप्रयोग प्राधिकरण को अलग से सत्यापित करें।
6. परिवर्तनों और गेटवे प्रतिक्रियाओं की जांच करें क्योंकि एक अलग परत आवश्यक क्षेत्रों को छोड़ सकती है।
7. वास्तविक ब्राउज़र संदर्भ के साथ मान्य करें; एक कमांड-लाइन सफलता यह नहीं साबित करती है कि ब्राउज़र नीति पास होती है।

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

CORS के लिए सुरक्षा और प्रेक्षणीयता

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

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

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

CORS को परिभाषित करने वाले मानक

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

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

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

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

सही CORS मानसिक मॉडल

CORS एक ब्राउज़र-निष्पादित प्रतिक्रिया-पठन अनुमति है जो सर्वर क्षेत्रों द्वारा नियंत्रित होती है; यह प्रामाणिकता, प्राधिकरण, कुकी नीति, और अनुरोध-धोखाधड़ी रक्षा को प्रतिस्थापित करने के बजाय उन्हें पूरा करता है।

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

संदर्भ

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