XMLHttpRequest XXX को 'नहीं' एक्सेस-कंट्रोल-अनुमति-उत्पत्ति 'हेडर लोड नहीं कर सकता है

Feb 22 2016

tl; डॉ; एक ही मूल नीति के बारे में

मेरे पास एक ग्रन्ट प्रक्रिया है जो एक्सप्रेस के उदाहरण की शुरुआत करती है। जेएस सर्वर। यह अब तक बिल्कुल ठीक काम कर रहा था जब यह क्रोम में डेवलपर के कंसोल (नवीनतम संस्करण) में त्रुटि लॉग में दिखाई देने वाले निम्न पेज के साथ एक रिक्त पृष्ठ की सेवा शुरू कर रहा था:

XMLHttpRequest लोड नहीं कर सकता https://www.example.com/ अनुरोधित संसाधन पर कोई 'एक्सेस-कंट्रोल-अनुमति-उत्पत्ति' हेडर मौजूद नहीं है। उत्पत्ति ' http: // localhost: 4300 ' इसलिए पहुंच की अनुमति नहीं है।

मुझे पृष्ठ तक पहुँचने से क्या रोक रहा है?

जवाब

224 Quentin Feb 22 2016 at 19:26

tl; dr - प्रासंगिक भागों को खोजने के लिए आसान बनाने के लिए अंत में एक सारांश और उत्तर में शीर्षासन है। सब कुछ पढ़ना हालांकि के रूप में यह समझने के लिए उपयोगी पृष्ठभूमि प्रदान करता है की सिफारिश की है क्यों कि देखकर कैसे बनाता है कैसे विभिन्न परिस्थितियों आसान में लागू होता है।

एक ही मूल नीति के बारे में

यह वही मूल नीति है । यह ब्राउज़रों द्वारा कार्यान्वित सुरक्षा सुविधा है।

आपका विशेष मामला यह दिखा रहा है कि इसे XMLHttpRequest के लिए कैसे लागू किया गया है (और यदि आपको भ्रूण का उपयोग करना था तो आपको समान परिणाम प्राप्त होंगे), लेकिन यह अन्य चीजों पर भी लागू होता है (जैसे कि चित्र <canvas>या दस्तावेज़ में लोड किए गए चित्र <iframe>), बस थोड़ा अलग कार्यान्वयन।

(अजीब तरह से, यह सीएसएस फोंट पर भी लागू होता है, लेकिन ऐसा इसलिए है क्योंकि फाउंड्री डीआरएम पर जोर देते हैं और सुरक्षा मुद्दों के लिए नहीं जो समान उत्पत्ति नीति आमतौर पर शामिल होती हैं)।

एसओपी की आवश्यकता को प्रदर्शित करने वाले मानक परिदृश्य को तीन वर्णों के साथ प्रदर्शित किया जा सकता है :

ऐलिस एक वेब ब्राउज़र वाला व्यक्ति है
बॉब एक वेबसाइट चलाता है ( https://www.[website].com/आपके उदाहरण में)
Mallory एक वेबसाइट चलाता है ( http://localhost:4300आपके उदाहरण में)

ऐलिस बॉब की साइट में लॉग इन है और वहां कुछ गोपनीय डेटा है। शायद यह एक कंपनी इंट्रानेट (लैन पर केवल ब्राउज़रों के लिए सुलभ) है, या उसका ऑनलाइन बैंकिंग (केवल एक उपयोगकर्ता नाम और पासवर्ड दर्ज करने के बाद आपको मिलने वाली कुकी के साथ सुलभ)।

ऐलिस मैलोरी की वेबसाइट पर जाता है, जिसमें कुछ जावास्क्रिप्ट हैं, जो एलिस के ब्राउज़र को बॉब की वेबसाइट (उसके कुकीज़, आदि के साथ उसके आईपी पते से) के लिए एक HTTP अनुरोध करने का कारण बनता है। यह प्रयोग करने XMLHttpRequestऔर पढ़ने के समान सरल हो सकता है responseText।

ब्राउज़र की समान उत्पत्ति नीति यह बताती है कि जावास्क्रिप्ट बॉब की वेबसाइट द्वारा लौटाए गए डेटा को पढ़ने से रोकता है (जो बॉब और ऐलिस मैलोरी को एक्सेस नहीं करना चाहते हैं)। (ध्यान दें कि आप उदाहरण के लिए, <img>मूल के पार एक तत्व का उपयोग करके एक छवि प्रदर्शित कर सकते हैं क्योंकि छवि की सामग्री जावास्क्रिप्ट (या Mallory) के संपर्क में नहीं है ... जब तक कि आप उस मिश्रण में कैनवास नहीं फेंकते हैं जिस स्थिति में आप एक ही-उत्पत्ति उत्पन्न करेंगे उल्लंघन त्रुटि)।

जब आप यह नहीं सोचते हैं तो समान उत्पत्ति नीति क्यों लागू होती है

किसी भी दिए गए URL के लिए यह संभव है कि SOP की आवश्यकता न हो। सामान्य परिदृश्यों के एक जोड़े जहां यह मामला है:

एलिस, बॉब और मैलोरी एक ही व्यक्ति हैं।
बॉब पूरी तरह से सार्वजनिक जानकारी प्रदान कर रहा है

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

क्यों समान उत्पत्ति नीति केवल एक वेब पेज में जावास्क्रिप्ट पर लागू होती है

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

कोई तीसरा पक्ष (मैलोरी) नहीं है जिसे जोखिम माना जाता है।

*क्रॉस-ऑरिजनल मुद्दों से बचने के लिए ब्राउज़र एक्सटेंशन को सावधानीपूर्वक लिखे जाने की आवश्यकता है। उदाहरण के लिए Chrome दस्तावेज़ देखें ।

आप जेएस के साथ पढ़ने के बिना पृष्ठ में डेटा क्यों प्रदर्शित कर सकते हैं

ऐसी कई परिस्थितियां हैं जहां मैलोरी की साइट किसी ब्राउज़र को किसी तृतीय पक्ष से डेटा प्राप्त करने और उसे प्रदर्शित करने का कारण बन सकती है (जैसे <img>किसी चित्र को प्रदर्शित करने के लिए एक तत्व जोड़कर )। मैलोरी के जावास्क्रिप्ट के लिए उस संसाधन में डेटा पढ़ना संभव नहीं है, हालांकि, केवल एलिस का ब्राउज़र और बॉब का सर्वर ऐसा कर सकते हैं, इसलिए यह अभी भी सुरक्षित है।

CORS

Access-Control-Allow-OriginHTTP प्रतिक्रिया हेडर में त्रुटि संदेश का हिस्सा है करने के लिए भेजा CORS मानक है जो बॉब स्पष्ट ऐलिस ब्राउज़र के माध्यम से डेटा का उपयोग करने के लिए मैलोरी की साइट के लिए अनुमति देनी अनुमति देता है।

एक मूल कार्यान्वयन में सिर्फ शामिल होगा:

Access-Control-Allow-Origin: *

… प्रतिक्रिया हेडर में किसी भी वेबसाइट को डेटा पढ़ने की अनुमति देने के लिए।

Access-Control-Allow-Origin: http://example.com/

… केवल एक विशिष्ट साइट को इसे एक्सेस करने की अनुमति देगा, और बॉब गतिशील रूप से उत्पन्न कर सकते हैं जो Origin अनुरोध शीर्षलेख के आधार पर कई को अनुमति दे सकते हैं, लेकिन सभी, साइटों को इसे एक्सेस करने के लिए नहीं।

बॉब की HTTP हेडर और / या सर्वर-साइड प्रोग्रामिंग लैंग्वेज पर प्रतिक्रिया हैडर किस प्रकार सेट करता है, इसकी बारीकियां। विभिन्न सामान्य कॉन्फ़िगरेशन के लिए गाइड का एक संग्रह है जो मदद कर सकता है।

एनबी: कुछ अनुरोध जटिल हैं और एक पूर्व- विकल्प विकल्प भेजते हैं जो सर्वर को जीईटी / पीओएसटी / पीयूटी / जो भी अनुरोध जेएस बनाना चाहते हैं, भेजने से पहले जवाब देना होगा। कोर के कार्यान्वयन जो केवल Access-Control-Allow-Originविशिष्ट URL में जोड़ते हैं, वे अक्सर इससे जुड़ जाते हैं।

स्पष्ट रूप से कॉर्स के माध्यम से अनुमति देना कुछ ऐसा है जो बॉब केवल तभी करेंगे:

डेटा निजी नहीं था या
मालोरी पर भरोसा किया गया

लेकिन मैं बॉब नहीं हूँ!

इस शीर्षक को जोड़ने के लिए मैलोरी के लिए कोई मानक तंत्र नहीं है क्योंकि इसे बॉब की वेबसाइट से आना है, जिसे वह नियंत्रित नहीं करता है।

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

त्रुटि संदेश जो "प्रीफ़लाइट के लिए प्रतिक्रिया" का उल्लेख करते हैं

कुछ क्रॉस मूल अनुरोध पूर्वनिर्मित हैं ।

ऐसा तब होता है जब (मोटे तौर पर बोलते हुए) आप एक क्रॉस-मूल अनुरोध करने की कोशिश करते हैं:

इसमें कुकीज़ जैसी साख शामिल है
एक नियमित HTML फॉर्म के साथ उत्पन्न नहीं किया जा सकता है (जैसे कस्टम हेडर या सामग्री-प्रकार जिसे आप किसी फॉर्म में उपयोग नहीं कर सकते हैं enctype)।

यदि आप सही ढंग से कुछ कर रहे हैं, जो एक प्रीफ़्लाइट की आवश्यकता है

इन मामलों में तब यह उत्तर बाकी भी लागू होता है, लेकिन आपको यह भी सुनिश्चित करने की आवश्यकता है कि सर्वर प्रीफ़लाइट अनुरोध के लिए सुन सकता है (जो होगा OPTIONS(और नहीं GET, POSTया जो भी आप भेजने की कोशिश कर रहे थे) और उसे सही जवाब दें Access-Control-Allow-Originहेडर लेकिन यह भी Access-Control-Allow-Methodsऔर Access-Control-Allow-Headersअपने विशिष्ट HTTP तरीकों या हेडर की अनुमति देने के लिए।

यदि आप गलती से प्रीफ़्लाइट को ट्रिगर कर रहे हैं

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

सामान्य गलतियाँ जो इसे ट्रिगर करती हैं:

Access-Control-Allow-Originअनुरोध पर अन्य कॉर्स प्रतिक्रिया हेडर डाल करने की कोशिश कर रहा है । ये अनुरोध पर संबंधित नहीं हैं, कुछ भी मददगार नहीं हैं (एक अनुमति प्रणाली की बात क्या होगी जहां आप अपने आप को अनुमति दे सकते हैं?), और केवल प्रतिक्रिया पर प्रदर्शित होना चाहिए।
Content-Type: application/jsonजीईटी अनुरोध पर एक हेडर लगाने की कोशिश करना जिसमें शरीर की सामग्री का वर्णन करने के लिए कोई अनुरोध नहीं है (आमतौर पर जब लेखक भ्रमित करता है Content-Typeऔर Accept)।

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

अपारदर्शी प्रतिक्रियाएं

कभी-कभी आपको HTTP अनुरोध करने की आवश्यकता होती है, लेकिन आपको प्रतिक्रिया पढ़ने की आवश्यकता नहीं है। जैसे अगर आप रिकॉर्डिंग के लिए सर्वर पर लॉग संदेश पोस्ट कर रहे हैं।

आप उपयोग कर रहे हैं एपीआई (बजाय ), तो आप इसे उपयोग CORS की कोशिश नहीं करने के लिए कॉन्फ़िगर कर सकते हैं।fetchXMLHttpRequest

ध्यान दें कि यह आपको ऐसा कुछ नहीं करने देगा जिसके लिए आपको CORS की आवश्यकता हो। आप प्रतिक्रिया नहीं पढ़ पाएंगे। आप एक अनुरोध करने में सक्षम नहीं होंगे जिसके लिए पहले से प्रकाश की आवश्यकता होती है।

यह आपको एक सरल अनुरोध करने देगा, प्रतिक्रिया नहीं देखेगा, और त्रुटि संदेशों के साथ डेवलपर कंसोल को नहीं भरेगा।

क्रोम त्रुटि संदेश द्वारा इसे कैसे समझाया जाता है जब आप उपयोग fetchकरते हुए अनुरोध करते हैं और कोर के साथ प्रतिक्रिया देखने की अनुमति नहीं मिलती है:

CORS नीति द्वारा https://example.com/' https://example.net' मूल ' ' पर लाने के लिए पहुँच अवरुद्ध कर दी गई है: Access-Control-Allow-Originअनुरोधित संसाधन पर कोई ' ' हेडर मौजूद नहीं है। यदि एक अपारदर्शी प्रतिक्रिया आपकी आवश्यकताओं को पूरा करती है, तो संसाधन को अक्षम करने के लिए 'नो-कॉर्स' के लिए अनुरोध के मोड को सेट करें।

इस प्रकार:

fetch("http://example.com", { mode: "no-cors" });

कोर के विकल्प

JSONP

बॉब JSONP की तरह एक हैक का उपयोग करके डेटा भी प्रदान कर सकता है कि कैसे लोगों ने कॉर्स के साथ आने से पहले अजाक्स को पार किया।

यह एक जावास्क्रिप्ट प्रोग्राम के रूप में डेटा को प्रस्तुत करके काम करता है जो मैलोरी के पेज में डेटा को इंजेक्ट करता है।

यह आवश्यक है कि मैलरी ट्रस्ट बॉब को दुर्भावनापूर्ण कोड प्रदान न करें।

सामान्य विषय पर ध्यान दें: डेटा प्रदान करने वाली साइट को ब्राउज़र को यह बताना होता है कि किसी तीसरे पक्ष की साइट के लिए यह ठीक है कि वह उस ब्राउज़र को भेज रहा है।

चूंकि JSONP <script>एक जावास्क्रिप्ट प्रोग्राम के रूप में डेटा लोड करने के लिए एक तत्व को जोड़कर काम करता है , जो पृष्ठ में पहले से ही एक फ़ंक्शन को कॉल करता है, JSONP तकनीक का उपयोग एक URL पर करने का प्रयास करता है, जो JSON देता है वह विफल हो जाएगा - आमतौर पर एक CORB त्रुटि के साथ - क्योंकि JSON जावास्क्रिप्ट नहीं है

एक मूल के लिए दो संसाधनों को स्थानांतरित करें

यदि HTML दस्तावेज़ JS में चलता है और अनुरोध किया जा रहा URL एक ही मूल पर है (समान योजना, होस्टनाम और पोर्ट साझा करते हुए) तो वे समान रूप से मूल नीति को डिफ़ॉल्ट रूप से अनुमति देते हैं। कोर की जरूरत नहीं है।

प्रॉक्सी

मैलोरी डेटा प्राप्त करने के लिए सर्वर-साइड कोड का उपयोग कर सकती है (जो वह तब अपने सर्वर से एलिस के ब्राउज़र को HTTP के माध्यम से हमेशा की तरह पास कर सकती थी)।

यह या तो होगा:

कोर हेडर जोड़ें
प्रतिक्रिया को JSONP में बदलें
HTML दस्तावेज़ के समान मूल पर मौजूद है

उस सर्वर-साइड कोड को थर्ड पार्टी (जैसे कोर्स एनीवेयर) द्वारा लिखा और होस्ट किया जा सकता है। इस के गोपनीयता निहितार्थों पर ध्यान दें: तीसरा पक्ष यह निगरानी कर सकता है कि उनके सर्वरों में क्या है।

बॉब को ऐसा करने के लिए कोई अनुमति देने की आवश्यकता नहीं होगी।

यहाँ कोई सुरक्षा निहितार्थ नहीं हैं क्योंकि यह केवल मालोरी और बॉब के बीच है। बॉब के लिए यह सोचने का कोई तरीका नहीं है कि मैलोरी ऐलिस है और मैलोरी को डेटा प्रदान करना है जिसे ऐलिस और बॉब के बीच गोपनीय रखा जाना चाहिए।

नतीजतन, मॉलोरी केवल सार्वजनिक डेटा पढ़ने के लिए इस तकनीक का उपयोग कर सकते हैं ।

हालाँकि, ध्यान दें कि किसी और की वेबसाइट से सामग्री लेना और उसे स्वयं प्रदर्शित करना कॉपीराइट का उल्लंघन हो सकता है और आपको कानूनी कार्रवाई तक खोल सकता है।

वेब ऐप के अलावा कुछ और लिखना

जैसा कि "व्हाईट ओरिजिन पॉलिसी केवल एक वेब पेज में जावास्क्रिप्ट पर लागू होता है" अनुभाग में उल्लेख किया गया है, आप वेब पेज में जावास्क्रिप्ट नहीं लिखकर एसओपी से बच सकते हैं।

इसका मतलब यह नहीं है कि आप जावास्क्रिप्ट और HTML का उपयोग जारी नहीं रख सकते हैं, लेकिन आप इसे कुछ अन्य तंत्र, जैसे कि नोड-वेबकिट या फोनगैप का उपयोग करके वितरित कर सकते हैं।

ब्राउज़र एक्सटेंशन

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

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

वे केवल सरल अनुरोधों के साथ काम करते हैं (असफल होने पर प्रीफ़लाइट विकल्प अनुरोधों को संभालना)।

स्थानीय विकास सर्वर के साथ उचित विकास का माहौल होना आमतौर पर एक बेहतर दृष्टिकोण है।

अन्य सुरक्षा जोखिम

ध्यान दें कि SOP / CORS XSS , CSRF , या SQL इंजेक्शन के हमलों को कम नहीं करता है जिन्हें स्वतंत्र रूप से नियंत्रित करने की आवश्यकता होती है।

सारांश

आपके क्लाइंट-साइड कोड में ऐसा कुछ भी नहीं है जो किसी अन्य के सर्वर तक कॉर्स की पहुंच को सक्षम कर सके ।
यदि आप सर्वर को नियंत्रित करते हैं तो अनुरोध किया जा रहा है: इसमें CORS अनुमतियां जोड़ें।
यदि आप इसे नियंत्रित करने वाले व्यक्ति के अनुकूल हैं: तो उन्हें इसके लिए CORS अनुमतियां जोड़ने के लिए प्राप्त करें।
यदि यह एक सार्वजनिक सेवा है:
- क्लाइंट-साइड जावास्क्रिप्ट के साथ इसे एक्सेस करने के बारे में वे क्या कहते हैं यह देखने के लिए उनके एपीआई प्रलेखन पढ़ें:
  - वे आपको विशिष्ट URL का उपयोग करने के लिए कह सकते हैं
  - वे JSONP का समर्थन कर सकते हैं
  - वे क्लाइंट-साइड कोड से क्रॉस-ऑरिजनल एक्सेस का समर्थन नहीं कर सकते हैं (यह सुरक्षा के आधार पर एक जानबूझकर निर्णय हो सकता है, खासकर यदि आपको प्रत्येक अनुरोध में एक व्यक्तिगत एपीआई कुंजी पारित करना है)।
- सुनिश्चित करें कि आप एक preflight अनुरोध को ट्रिगर नहीं कर रहे हैं जिसकी आपको आवश्यकता नहीं है। एपीआई सरल अनुरोधों के लिए अनुमति दे सकता है लेकिन पूर्व-स्वीकृत अनुरोध नहीं।
यदि उपरोक्त में से कोई भी लागू नहीं होता है: इसके बजाय अपने सर्वर से बात करने के लिए ब्राउज़र प्राप्त करें , और फिर अपने सर्वर को दूसरे सर्वर से डेटा प्राप्त करें और इसे पास करें। (थर्ड-पार्टी होस्टेड सर्विस भी हैं जो कॉर्स् हेडर्स को पबली एक्सेस करने योग्य संसाधनों से जोड़ते हैं जो आप उपयोग कर सकते हैं)।

4 Daphoque Sep 09 2016 at 17:45

लक्ष्य सर्वर को क्रॉस-ऑरिजिन अनुरोध की अनुमति देनी चाहिए। एक्सप्रेस के माध्यम से इसे अनुमति देने के लिए, बस http विकल्प अनुरोध को संभालें:

app.options('/url...', function(req, res, next){
   res.header('Access-Control-Allow-Origin', "*");
   res.header('Access-Control-Allow-Methods', 'POST');
   res.header("Access-Control-Allow-Headers", "accept, content-type");
   res.header("Access-Control-Max-Age", "1728000");
   return res.sendStatus(200);
});

3 zwif Nov 09 2017 at 18:37

जैसा कि स्वीकार किए गए उत्तर में इसका उल्लेख नहीं किया गया है।

यह इस सटीक प्रश्न के लिए मामला नहीं है, लेकिन दूसरों की मदद कर सकता है जो उस समस्या की खोज करते हैं
यह कुछ ऐसा है जो आप अपने क्लाइंट-कोड में कर सकते हैं ताकि कुछ मामलों में कॉर्स त्रुटियों को रोका जा सके ।

आप सरल अनुरोधों का उपयोग कर सकते हैं ।
'सरल अनुरोध' करने के लिए अनुरोध को कई शर्तों को पूरा करने की आवश्यकता है। जैसे केवल अनुमति देना POST, GETऔर HEADविधि, साथ ही केवल कुछ दिए गए हेडर्स की अनुमति देना (आप यहां सभी शर्तें पा सकते हैं )।

यदि आपका क्लाइंट कोड प्रभावित हेडर को स्पष्ट रूप से सेट नहीं करता है (उदाहरण के लिए "स्वीकार करें"), तो अनुरोध में एक निश्चित मूल्य के साथ यह हो सकता है कि कुछ क्लाइंट इन हेडरों को स्वचालित रूप से कुछ "गैर-मानक" मानों के साथ सेट करते हैं, जिससे सर्वर इसे स्वीकार नहीं करता है। सरल अनुरोध - जो आपको एक कोर त्रुटि देगा।

2 Vishnu Feb 22 2016 at 19:32

यह कॉर्स त्रुटि के कारण हो रहा है। CORS का अर्थ है क्रॉस ओरिजिनल रिसोर्स शेयरिंग। सरल शब्दों में, यह त्रुटि तब होती है जब हम किसी डोमेन / संसाधन को दूसरे डोमेन से एक्सेस करने का प्रयास करते हैं।

इसके बारे में यहाँ और पढ़ें: jquery के साथ CORS त्रुटि

इसे ठीक करने के लिए, यदि आपके पास अन्य डोमेन तक पहुँच है, तो आपको सर्वर में Access-Control-Allow-Origin की अनुमति देनी होगी। यह हेडर में जोड़ा जा सकता है। आप इसे सभी अनुरोधों / डोमेन या किसी विशिष्ट डोमेन के लिए सक्षम कर सकते हैं।

क्रॉस-ऑरिजनल रिसोर्स शेयरिंग (कोर) पोस्ट अनुरोध कैसे प्राप्त करें

ये लिंक मदद कर सकते हैं

morph85 Dec 17 2018 at 13:40

यह कोर मुद्दा आगे (अन्य कारणों के लिए) विस्तृत नहीं था।

मैं इस मुद्दे को अलग कारण से वर्तमान में कर रहा हूँ। मेरा फ्रंट एंड 'एक्सेस-कंट्रोल-अलाउंस-ओरिजिन' हेडर एरर भी लौटा रहा है।

बस मैंने गलत URL को इंगित किया है, इसलिए यह हेडर ठीक से परिलक्षित नहीं हुआ (जिसमें मैंने ऐसा किया मान लिया)। लोकलहोस्ट (सामने का छोर) -> गैर सुरक्षित http (जिसे https माना जाता है) को कॉल करें, सुनिश्चित करें कि सामने के छोर से एपीआई अंत बिंदु सही प्रोटोकॉल की ओर इशारा कर रहा है।

Subhashi Feb 11 2020 at 18:02

मुझे क्रोम कंसोल में वही त्रुटि मिली।

मेरी समस्या थी, मैं http://इसके बजाय का उपयोग करके साइट पर जाने की कोशिश कर रहा था https://। तो ठीक करने के लिए कुछ भी नहीं था, बस उसी साइट का उपयोग करके जाना था https।

HungNM2 Aug 20 2020 at 09:13

इस बग ने मुझे 2 दिन का समय दिया। मैंने अपना सर्वर लॉग चेक किया, ब्राउज़र क्रोम / एज और सर्वर के बीच प्रीफ़लाइट विकल्प अनुरोध / प्रतिक्रिया ठीक थी। इसका मुख्य कारण यह है कि XHTMLRequest के लिए GET / POST / PUT / DELETE सर्वर प्रतिक्रिया के लिए निम्नलिखित हेडर भी होना चाहिए:

access-control-allow-origin: origin

"मूल" अनुरोध शीर्षलेख में है (ब्राउज़र आपके लिए अनुरोध करने के लिए इसे जोड़ देगा)। उदाहरण के लिए:

Origin: http://localhost:4221

आप सभी के लिए स्वीकार करने के लिए प्रतिक्रिया शीर्षलेख जैसे जोड़ सकते हैं:

access-control-allow-origin: *

या विशिष्ट अनुरोध के लिए प्रतिक्रिया शीर्षलेख जैसे:

access-control-allow-origin: http://localhost:4221

ब्राउज़र में संदेश समझने के लिए स्पष्ट नहीं है: "... अनुरोधित संसाधन"

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

कैसे देखें कि किसी सरणी में 2 या अधिक तत्व हैं जो समान हैं? [डुप्लिकेट]

“ $\Sigma_1^1$-पीनो अंकगणित ”- क्या यह नीचे पिन करता है $\mathbb{N}$?

विशिष्ट पाठ कैसे प्राप्त करें जो div वर्ग से संबंधित है

एक्सोडस में "शोन" के लिए एक असामान्य हिब्रू शब्द का उपयोग

स्वास्थ्य समस्याओं के कारण छात्र को अस्वीकार करने वाले पीएचडी सलाहकार के संबंध में

शहरों में युद्ध छेड़ने का फैसला क्या है?

मूसा के नेताओं का समूह एक्सोडस 18:21

विल्सन प्रभाव: सनस्पॉट कितने "गहरे" हैं?

मध्ययुगीन समय में सड़कों पर गति की सीमाओं की निगरानी कैसे करें? [डुप्लिकेट]

सिद्ध है कि एक अनुक्रम $\{a_n\}_n$ द्वारा परिभाषित $a_1=-\frac14$ तथा $-a_{n+1}=\frac{a_na_{n+1}+4}4$ अभिसरण है और इसकी सीमा पाते हैं।

के बेहतर अभिसरण के लिए स्टर्न-ब्रोकोट पेड़ को नियोजित किया जा सकता है $2^m/3^n$?

शनि के छल्ले कैसे निकालें?