CORS क्या है?

Scrapeless एजेंट ब्राउज़र उन ब्राउज़र सत्रों को चलाता है जो यह देख सकते हैं कि एक वेबसाइट ब्राउज़र के क्रॉस-Origin नियमों के तहत कैसे व्यवहार करती है।

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

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

उत्पत्ति सीमा पर CORS लागू होता है

दो URLs केवल तभी एक उत्पत्ति साझा करते हैं जब उनकी योजना, होस्ट और पोर्ट मेल खाते हैं। http से https पर बदलना, एक उपडोमेन में जाना, या एक अन्य पोर्ट का उपयोग करना एक अलग उत्पत्ति बनाता है। एक पृष्ठ कुछ क्रॉस-Origin अनुरोध कर सकता है बिना प्रतिक्रिया शरीर तक पहुँचने के। MDN CORS गाइड इसका वर्णन क्रॉस-Origin HTTP अनुरोधों के लिए समान-Origin नीति का नियंत्रित विश्राम के रूप में करता है जो स्क्रिप्ट द्वारा किए जाते हैं।

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

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

सरल अनुरोध और प्रीफ़्लाइट अनुरोध

कुछ क्रॉस-Origin अनुरोधों के लिए, ब्राउज़र वास्तविक अनुरोध भेजता है और फिर प्रतिक्रिया अनुमति की जांच करता है। अन्य अनुरोधों को एक प्रीफ़्लाइट की आवश्यकता होती है: ब्राउज़र पहले एक OPTIONS अनुरोध भेजता है यह पूछने के लिए कि क्या प्रस्तावित विधि और हेडर अनुमत हैं। प्रीफ़्लाइट परिभाषा Origin और Access-Control-Request-Method फ़ील्डों की पहचान करती है, जब आवश्यक हो तो Access-Control-Request-Headers के साथ।

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

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

क्रेडेंशियल्स प्रतिक्रिया नियमों को बदलते हैं

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

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

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

ब्राउज़र CORS विफलता का निदान कैसे करें

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

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

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

ब्राउज़र स्वचालन और डेटा संग्रह में CORS

एक असली ब्राउज़र सत्र ब्राउज़र सुरक्षा नियमों के तहत पृष्ठ स्क्रिप्ट को निष्पादित करता है। Scrapeless Agent Browser दूर से नियंत्रित ब्राउज़र निष्पादन प्रदान करता है, ताकि एक पृष्ठ क्रॉस-स्रोत अनुरोध कर सके और उस वातावरण में देखा जा सके। एजेंट ब्राउज़र परिचय ब्राउज़र उत्पाद का वर्णन करता है। यह एक अनधिकृत एपीआई उत्तर को अधिकृत में नहीं बदलता।

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

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

एक व्यावहारिक CORS निर्णय चेकलिस्ट

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

उत्पादन में इस्तेमाल किए गए सटीक विधि और Headers का परीक्षण करें। कस्टम फ़ील्ड के बिना एक GET काम कर सकता है जबकि एक अधिकारHeaders के साथ JSON POST पूर्व उड़ान को ट्रिगर करता है। त्रुटि पथ का भी परीक्षण करें: यदि प्रमाणीकरण विफलता या रीडायरेक्ट उन्हें छोड़ देते हैं, तो सही CORS Headers के साथ एक सफलता उत्तर अपर्याप्त होता है। ब्राउज़र उपयोगकर्ताओं को असली विफलता को स्पष्ट और निदान योग्य होना आवश्यक है।

अंततः, घटना नोट्स में तीन अवलोकनों को अलग करें: क्या नेटवर्क अनुरोध किया गया था, क्या सर्वर ने ऑपरेशन को स्वीकार किया, और क्या ब्राउज़र ने पृष्ठ स्क्रिप्ट को उत्तर प्रदर्शित किया। उन उत्तरों में भिन्नता हो सकती है। उन्हें अलग रखना एक ब्राउज़र नीति मुद्दे को “ठीक” करने से रोकता है जिससे अप्रासंगिक सर्वर प्राधिकरण कमजोर हो सकता है।

निष्कर्ष

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