Access-Control-Allow-Origin हेडर कैसे काम करता है?

Question

जाहिर है, मैंने इसके शब्दार्थ को पूरी तरह गलत समझा है। मैंने कुछ इस तरह से सोचा:

1. एक ग्राहक जावास्क्रिप्ट कोड MyCode.js डाउनलोड करता है http://siteA- मूल से ।
2. MyCode.js के प्रतिसाद शीर्ष लेख में Access-Control-Allow-Origin होता है:,http://siteB जिसके बारे में मुझे लगा कि MyCode.js को साइट B पर क्रॉस-ऑरिजनल संदर्भ बनाने की अनुमति थी।
3. क्लाइंट MyCode.js की कुछ कार्यक्षमता को ट्रिगर करता है, जो बदले में http://siteBक्रॉस- ऑरिजिनल रिक्वेस्ट होने के बावजूद अनुरोध करता है , जो ठीक होना चाहिए।

खैर, मैं गलत हूं। यह इस तरह से काम नहीं करता है। तो, मैं पढ़ लिया है क्रॉस-ओरिजिन संसाधन साझा करने और पढ़ने के लिए प्रयास किया W3C सिफारिश में क्रॉस ओरिजिन रिसोर्स शेयरिंग

एक बात सुनिश्चित है - मुझे अभी भी समझ में नहीं आया कि मैं इस हेडर का उपयोग कैसे करूं।

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

पुनश्च

मैं JSONP का उपयोग नहीं करना चाहता।

Comments

मुझे यकीन नहीं है, लेकिन मेरा मानना ​​है कि हेडर को इस तरह सेट करने से साइट बी पर कोड लाने की अनुमति मिलती है http://siteA/MyCode.js।

— pimvdb

पर कैसे??? हेडर मान प्राप्त करने के लिए पहले संसाधन को लाना पड़ता है, लेकिन संसाधन क्रॉस-ऑरिजनल है और इसलिए ब्राउज़र को पहले स्थान पर अनुरोध को ब्लॉक नहीं करना चाहिए?

— मार्क

आपके द्वारा वर्णित वास्तव में एक और अभ्यास जैसा दिखता है, सामग्री सुरक्षा नीति

— एलेक्स

@ आपको हेडर प्राप्त करने के लिए संसाधन लाने की आवश्यकता नहीं है। HTTP हेडर विधि केवल हेडर लौटाएगी। और कॉर्स के मामले में, HTTP विकल्प विधि का उपयोग करके एक प्रीफ़्लाइट चेक किया जाता है जो शरीर को वापस नहीं करता है। apsillers जवाब इस अच्छी तरह से stackoverflow.com/posts/10636765/revisions का वर्णन करता है ।

— मैथ्यू

Answer 1

Access-Control-Allow-Originएक CORS (क्रॉस-ऑरिजनल रिसोर्स शेयरिंग) हैडर है ।

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

प्रत्येक साइट / साइट के लिए जो साइट बी साइट ए के लिए सुलभ बनाना चाहती है, साइट बी को अपने पृष्ठों की प्रतिक्रिया हेडर के साथ देनी चाहिए:

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

आधुनिक ब्राउज़र क्रॉस-डोमेन अनुरोधों को एकमुश्त ब्लॉक नहीं करेंगे। यदि साइट ए साइट बी से एक पृष्ठ का अनुरोध करती है, तो ब्राउज़र वास्तव में नेटवर्क स्तर पर अनुरोधित पृष्ठ को लाएगा और जांच करेगा कि प्रतिक्रिया हेडर साइट ए को अनुमति प्राप्त आवश्यक डोमेन के रूप में सूचीबद्ध करता है या नहीं। यदि साइट B ने यह संकेत नहीं दिया है कि साइट A को इस पृष्ठ तक पहुंचने की अनुमति है, तो ब्राउज़र XMLHttpRequest's errorघटना को ट्रिगर करेगा और जावास्क्रिप्ट कोड का अनुरोध करने पर प्रतिक्रिया डेटा से इनकार करेगा।

गैर-सरल अनुरोध

नेटवर्क स्तर पर क्या होता है, ऊपर बताए गए की तुलना में थोड़ा अधिक जटिल हो सकता है। यदि अनुरोध एक "गैर-सरल" अनुरोध है , तो ब्राउज़र पहले यह सत्यापित करने के लिए कि डेटा अनुरोध को स्वीकार करेगा, डेटा-कम "प्रीफ़लाइट" विकल्प अनुरोध भेजता है। एक अनुरोध गैर-सरल है जब या तो (या दोनों):

• GET या POST के अलावा HTTP क्रिया का उपयोग करना (जैसे PUT, DELETE)
• गैर-सरल अनुरोध हेडर का उपयोग करना; केवल साधारण अनुरोध हेडर हैं:
  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type(यह केवल सरल जब अपने मूल्य है application/x-www-form-urlencoded, multipart/form-dataया text/plain)

यदि सर्वर उपयुक्त प्रतिक्रिया हेडर ( Access-Control-Allow-Headersगैर-साधारण हेडर के लिए, Access-Control-Allow-Methodsगैर-सरल क्रियाओं के लिए) के विकल्प का जवाब देता है, जो गैर-सरल क्रिया और / या गैर-साधारण हेडर से मेल खाता है, तो ब्राउज़र वास्तविक अनुरोध भेजता है।

यह मानते हुए कि साइट A /somePageएक गैर-साधारण Content-Typeमान के साथ एक PUT अनुरोध भेजना चाहती है application/json, ब्राउज़र पहले एक पूर्व-भुगतान संदेश भेजेगा:

OPTIONS /somePage HTTP/1.1
Origin: http://siteA.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type

ध्यान दें कि Access-Control-Request-Methodऔर Access-Control-Request-Headersब्राउज़र द्वारा स्वचालित रूप से जोड़ा जाता है; आपको उन्हें जोड़ने की आवश्यकता नहीं है। यह विकल्प प्रीफ़्लाइट को सफल प्रतिसाद हेडर देता है:

Access-Control-Allow-Origin: http://siteA.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type

वास्तविक अनुरोध भेजते समय (प्रीफ़्लाइट होने के बाद), व्यवहार एक साधारण अनुरोध को संभालने के समान है। दूसरे शब्दों में, एक गैर-सरल अनुरोध जिसका प्रीफ़्लाइट सफल है उसे एक साधारण अनुरोध के रूप में माना जाता है (यानी, सर्वर को अभी भी Access-Control-Allow-Originवास्तविक प्रतिक्रिया के लिए फिर से भेजना होगा )।

ब्राउज़र वास्तविक अनुरोध भेजता है:

PUT /somePage HTTP/1.1
Origin: http://siteA.com
Content-Type: application/json

{ "myRequestContent": "JSON is so great" }

और सर्वर एक वापस भेज देता है Access-Control-Allow-Origin, जैसे कि यह एक साधारण अनुरोध के लिए होगा:

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

गैर-सरल अनुरोधों के बारे में थोड़ी अधिक जानकारी के लिए CORS पर XMLHttpRequest को समझना देखें ।

Comments

लेकिन MyCode.js पहले स्थान पर साइट B के लिए नहीं पहुँच सकते हैं! यह हेडर क्लाइंट में कैसे आएगा? BTW, अवतार में प्रकाश जीवन ग्लाइडर के लिए यश।

— मार्क

मैंने स्पष्टीकरण के साथ संपादित किया: ब्राउज़र वास्तव में Access-Control-Allow-Originहेडर की जांच करने के लिए साइट बी पर एक नेटवर्क प्राप्त करता है , लेकिन यह साइट ए पर जेएस कोड का जवाब नहीं दे सकता है यदि हेडर साइट ए को अनुमति नहीं देता है। (पीएस धन्यवाद :))

— अप्सिलर्स

वास्तव में, मैं फ़िडलर में डाउनलोड का कोई रिकॉर्ड नहीं देखता हूं, जब तक कि क्रॉस-ऑरिजिन अनुरोध को मंजूरी नहीं दी जाती है। दिलचस्प है ...

— अंक

@ Jwan622 एक मौलिक " क्यों? " जैसा प्रश्न शायद इस विशेष उत्तर के लिए गुंजाइश से बाहर है, जो कि नियमों और यांत्रिकी के बारे में है। मूल रूप से, ब्राउज़र आपको अनुमति देता है , कंप्यूटर पर बैठा मानव, किसी भी उत्पत्ति के किसी भी संसाधन को देखता है। यह स्क्रिप्ट को पढ़ना बंद कर देता है (जो किसी के द्वारा भी लिखा जा सकता है) स्क्रिप्ट को पढ़ने वाले पेज के मूल से अलग संसाधनों से पढ़ना। कुछ संबंधित प्रश्न programmers.stackexchange.com/q/216605 हैं और समान मूल नीति के लिए खतरा मॉडल क्या है?

— अप्सिलर्स

प्रमाणीकरण का उपयोग करने के मामले में, कुछ ब्राउज़रों (FF और Chrome AFAIK) में Access-Control-Allow-Originस्वीकार नहीं करता है *। तो इस मामले में आपको Originहेडर से मूल्य निर्दिष्ट करना होगा । आशा है कि यह किसी की मदद करेगा।

— जसोल्टी

Answer 2

क्रॉस-ऑरिजनल रिसोर्स शेयरिंग - CORS(AKA क्रॉस-डोमेन AJAX अनुरोध) एक ऐसा मुद्दा है, जो ज्यादातर वेब डेवलपर्स को मिल सकता है, समान-उत्पत्ति-नीति के अनुसार, ब्राउज़र्स क्लाइंट जावास्क्रिप्ट को एक सुरक्षा सैंडबॉक्स में प्रतिबंधित करते हैं, आमतौर पर JS एक दूरस्थ सर्वर के साथ सीधे संवाद नहीं कर सकते हैं। एक अलग डोमेन से। पिछले डेवलपर्स में क्रॉस-डोमेन संसाधन अनुरोध को प्राप्त करने के लिए कई पेचीदा तरीके बनाए गए, जिनमें से अधिकतर का उपयोग करने के तरीके निम्न हैं:

1. रिमोट के साथ संचार करने के लिए "प्रॉक्सी" के रूप में फ्लैश / सिल्वरलाइट या सर्वर साइड का उपयोग करें।
2. JSON पैडिंग के साथ ( JSONP )।
3. एक iframe में दूरस्थ सर्वर को एम्बेड करता है और खंड या window.name के माध्यम से संवाद करता है, यहां देखें ।

उन पेचीदा तरीकों में कम या ज्यादा कुछ मुद्दे हैं, उदाहरण के लिए JSONP में सुरक्षा छेद हो सकता है यदि डेवलपर्स इसे केवल "eval" करते हैं, और # 3 ऊपर, हालांकि यह काम करता है, दोनों डोमेन को एक दूसरे के बीच सख्त अनुबंध बनाना चाहिए, यह न तो लचीला है और न ही सुरुचिपूर्ण है। IMHO:)

W3C ने इस मुद्दे को हल करने के लिए एक सुरक्षित, लचीला और एक अनुशंसित मानक तरीका प्रदान करने के लिए मानक समाधान के रूप में क्रॉस-ऑरिजनल रिसोर्स शेयरिंग (CORS) की शुरुआत की थी।

यांत्रिकी

एक उच्च स्तर से हम केवल डीईएम कॉर्स को डी एएएक्स कॉल कर सकते हैं जो कि डोमेन ए से ग्राहक एएएक्सएक्स कॉल और डोमेन बी पर होस्ट किए गए पृष्ठ, एक विशिष्ट क्रॉस-ऑरिजनल अनुरोध / प्रतिक्रिया होगी:

DomainA AJAX हेडर का अनुरोध करता है

Host DomainB.com
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,application/json
Accept-Language en-us;
Accept-Encoding gzip, deflate
Keep-Alive 115
Origin http://DomainA.com 

डोमेनबी प्रतिक्रिया हेडर

Cache-Control private
Content-Type application/json; charset=utf-8
Access-Control-Allow-Origin DomainA.com
Content-Length 87
Proxy-Connection Keep-Alive
Connection Keep-Alive

ऊपर जिन नीले हिस्सों को मैंने चिह्नित किया था वे गुठली के तथ्य थे, "उत्पत्ति" अनुरोध हेडर "इंगित करता है कि क्रॉस-ऑरिजनल अनुरोध या प्रीफ़्लाइट अनुरोध कहाँ से उत्पन्न होता है", "एक्सेस-कंट्रोल-अनुमति-उत्पत्ति" प्रतिक्रिया हैडर इंगित करता है कि यह पृष्ठ दूरस्थ अनुरोध की अनुमति देता है DomainA (यदि मान है * संकेत किसी भी डोमेन से दूरस्थ अनुरोध की अनुमति देता है)।

जैसा कि मैंने ऊपर बताया, वास्तव में क्रॉस-ओरिजिन HTTP अनुरोध को सबमिट करने से पहले W3 ने ब्राउज़र को " प्रीफ़लाइट अनुरोध " को लागू करने की सिफारिश की , संक्षेप में यह एक HTTP OPTIONSअनुरोध है:

OPTIONS DomainB.com/foo.aspx HTTP/1.1

यदि foo.aspx विकल्प HTTP क्रिया का समर्थन करता है, तो यह नीचे की तरह प्रतिक्रिया दे सकता है:

HTTP/1.1 200 OK
Date: Wed, 01 Mar 2011 15:38:19 GMT
Access-Control-Allow-Origin: http://DomainA.com
Access-Control-Allow-Methods: POST, GET, OPTIONS, HEAD
Access-Control-Allow-Headers: X-Requested-With
Access-Control-Max-Age: 1728000
Connection: Keep-Alive
Content-Type: application/json

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

मैंने तीन साल पहले CORS के बारे में ब्लॉग किया था: AJAX क्रॉस-ओरिजिन HTTP अनुरोध

Comments

इस जवाब ने मुझे एहसास दिलाया कि मैं इस हेडर को पोस्ट और जीईटी अनुरोधों का उपयोग किए बिना अचानक क्यों मुद्दा बना रहा था। मैंने डिस्क से सीधे index.html फ़ाइल खोली थी, इसलिए जिस क्लाइंट को नोड पर एक्सेस करना था। js को क्रॉस-डोमेन माना जाता था, जबकि यह केवल लोकलहोस्ट पर चल रहा था। URL के माध्यम से एक्सेस करना (जैसा कि आम तौर पर होगा) मेरी समस्या को "हल" किया जाता है ...

— LuqJensen

बाहरी नेटवर्क में एक डोमेन एक आंतरिक नेटवर्क पर एक डोमेन के साथ संचार करने में सक्षम होगा?

— 8 बजे Si8

Answer 3

प्रश्न उत्तर देने के लिए थोड़ा पुराना है, लेकिन मैं इस प्रश्न के भविष्य के संदर्भ के लिए इसे पोस्ट कर रहा हूं।

इस मोज़िला डेवलपर नेटवर्क लेख के अनुसार ,

एक संसाधन क्रॉस-ओरिजिनल HTTP अनुरोध करता है जब वह किसी भिन्न डोमेन से संसाधन का अनुरोध करता है, या उस पोर्ट से पोर्ट करता है जो पहले संसाधन स्वयं कार्य करता है।

एक HTML पृष्ठ से सेवा की http://domain-a.comएक बनाता है <img>के लिए स्रोत अनुरोध http://domain-b.com/image.jpg।
वेब पर कई पेज आज सीएसएस स्टाइलशीट , इमेज और स्क्रिप्ट जैसे संसाधनों को अलग-अलग डोमेन से लोड करते हैं (इस प्रकार यह शांत होना चाहिए)।

समान-मूल नीति

सुरक्षा कारणों से, ब्राउज़र स्क्रिप्ट के भीतर से शुरू किए गए क्रॉस-मूल HTTP अनुरोधों को प्रतिबंधित करते हैं ।
उदाहरण के लिए, XMLHttpRequestऔर समान-मूल नीतिFetch का पालन करें । तो, एक वेब एप्लिकेशन का उपयोग करके या केवल अपने स्वयं के डोमेन के लिए HTTP अनुरोध कर सकते हैं ।
XMLHttpRequestFetch

क्रॉस-ओरिजिनल रिसोर्स शेयरिंग (कोर)

वेब अनुप्रयोगों को बेहतर बनाने के लिए, डेवलपर्स ने ब्राउज़र विक्रेताओं से क्रॉस-डोमेन अनुरोधों की अनुमति देने के लिए कहा।

क्रॉस-उत्पत्ति रिसोर्स शेयरिंग (CORS) तंत्र वेब सर्वर देता क्रॉस-डोमेन का उपयोग नियंत्रण है, जो सुरक्षित क्रॉस-डोमेन डाटा हस्तांतरण को सक्षम करें।
आधुनिक ब्राउज़र एक एपीआई कंटेनर में कॉर्स का उपयोग करते हैं - जैसे कि - या - क्रॉस-मूल HTTP अनुरोधों के जोखिमों को कम करने के लिए।XMLHttpRequestFetch

कोर कैसे काम करता है ( Access-Control-Allow-Originहेडर)

विकिपीडिया :

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

हालाँकि सर्वर द्वारा कुछ सत्यापन और प्राधिकरण किया जा सकता है, यह आमतौर पर ब्राउज़र की ज़िम्मेदारी है कि वह इन हेडरों का समर्थन करे और प्रतिबंधों का सम्मान करे।

उदाहरण

1. ब्राउज़र OPTIONSएक Origin HTTPहेडर के साथ अनुरोध भेजता है ।

   इस हेडर का मूल्य वह डोमेन है जिसने मूल पृष्ठ पर काम किया है। जब http://www.example.comउपयोगकर्ता के डेटा तक पहुंचने के प्रयासों का एक पृष्ठ service.example.com, निम्नलिखित अनुरोध शीर्षलेख को भेजा जाएगा service.example.com:

   उत्पत्ति: http://www.example.com

2. सर्वर पर service.example.comइसके साथ प्रतिक्रिया हो सकती है:

   • Access-Control-Allow-Originइसकी प्रतिक्रिया में एक (ACAO) हेडर जो यह दर्शाता है कि मूल साइट की अनुमति है।
     उदाहरण के लिए:

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

   • यदि सर्वर क्रॉस-ऑरिजनल रिक्वेस्ट को अनुमति नहीं देता है तो एक त्रुटि पृष्ठ

   • Access-Control-Allow-Originवाइल्डकार्ड वाला एक (ACAO) हेडर जो सभी डोमेन को अनुमति देता है:

     Access-Control-Allow-Origin: *

Comments

सेट करने के लिए किसी को भी अनुमति नहीं दी जाती है कि कुछ चीज़ों की अनुमति दें जैसेAccess-Control-Allow-Origin:null

— सुबिन चालिल

जब मैं किसी को अपने संसाधनों को कॉर्स के माध्यम से एक्सेस करने की अनुमति नहीं देना चाहता हूं, तो मुझे किस मूल्य के लिए सेट करना चाहिए Access-Control-Allow-Origin? मेरा मतलब हैAccess-Control-Allow-Origin: *

— १३:५३ पर सबिन चालिल

बस उस उद्देश्य के लिए कुछ भी निर्धारित न करें

— Pmpr

Answer 4

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

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

कभी-कभी आपको क्रॉस डोमेन पर काम करने की आवश्यकता होती है, जो कि CORS में आता है। CORS domainB.com के लिए समान मूल नीति को शिथिल करता है, Access-Control-Allow-Originहेडर का उपयोग करके अन्य डोमेन (domainA.com) को सूचीबद्ध करने के लिए विश्वसनीय है जो जावास्क्रिप्ट को चलाने के लिए विश्वसनीय है जो कि डोमेन के साथ बातचीत कर सकता है। कॉम।

यह समझने के लिए कि कौन से डोमेन को कोर हेडर की सेवा करनी चाहिए, इस पर विचार करें। आप malicious.com पर जाते हैं, जिसमें कुछ JavaScript शामिल हैं जो mybank.com पर एक क्रॉस डोमेन अनुरोध करने की कोशिश करती है। यह तय करने के लिए कि क्या यह ठीक है या नहीं, यह तय करने के लिए mybank.com, malicious.com पर निर्भर होना चाहिए, जो कि उसी मूल नीति को निर्धारित करता है, जो जावास्क्रिप्ट को दुर्भावनापूर्ण.कॉम से अनुमति देती है, ताकि उसके साथ बातचीत की जा सके। अगर malicous.com अपने स्वयं के जावास्क्रिप्ट हेडर को mybank.com पर अपने स्वयं के जावास्क्रिप्ट एक्सेस की अनुमति दे सकता है, तो यह उसी मूल नीति को पूरी तरह से रद्द कर देगा।

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

Comments

अनुच्छेद 2 को देखते हुए, क्या आपके पास साइट 3 में साइटबी, साइटबी पीछे की ओर है? मुझे गलतफहमी हो सकती है, लेकिन पहले के पैराग्राफ से लगता है कि इसके साइट का मतलब है कि जेएस सवाल पर चल रहा है?

— cellepo

Answer 5

1. एक ग्राहक जावास्क्रिप्ट कोड MyCode.js को http: // siteA - मूल से डाउनलोड करता है।

वह कोड जो डाउनलोडिंग करता है - आपका HTML स्क्रिप्ट टैग या जावास्क्रिप्ट से जावास्क्रिप्ट या जो भी - से आया, आइए कहते हैं http: - साइटज़ । और, जब ब्राउज़र MyCode.js का अनुरोध करता है, तो यह एक उत्पत्ति भेजता है: हेडर "उत्पत्ति: http: // siteZ " कहकर , क्योंकि यह देख सकता है कि आप साइट और साइटज! = साइट के लिए अनुरोध कर रहे हैं। (आप इसे रोक या हस्तक्षेप नहीं कर सकते।)

2. MyCode.js के प्रतिक्रिया हेडर में Access-Control-Allow-Origin: http: // siteB शामिल है , जो मुझे लगा कि इसका मतलब है कि MyCode.js को साइट B पर क्रॉस-ऑरिजनल संदर्भ बनाने की अनुमति थी।

नहीं। इसका मतलब है, केवल साइटबी को यह अनुरोध करने की अनुमति है। इसलिए siteZ से MyCode.js के लिए आपके अनुरोध के बजाय एक त्रुटि मिलती है, और ब्राउज़र आमतौर पर आपको कुछ नहीं देता है। लेकिन अगर आप अपना सर्वर ACAO: siteZ के बदले देते हैं, तो आपको MyCode.js मिल जाएगा। या अगर यह '*' भेजता है, तो वह काम करेगा, जो हर किसी को अंदर जाने देगा। या यदि सर्वर हमेशा स्ट्रिंग को उत्पत्ति से भेजता है: हैडर ... लेकिन ... सुरक्षा के लिए, यदि आप हैकर्स से डरते हैं। , आपके सर्वर को केवल एक शॉर्टलिस्ट पर उत्पत्ति की अनुमति चाहिए, जो उन अनुरोधों को बनाने की अनुमति है।

फिर, MyCode.js साइटए से आता है। जब यह साइटबी से अनुरोध करता है, तो वे सभी क्रॉस-ऑरिजनल होते हैं, ब्राउज़र ओरिजिन भेजता है: साइटए, और साइटबी को साइटए को लेना होता है, यह अनुमति प्राप्त अनुरोधकर्ताओं की छोटी सूची पर पहचान करता है, और एसीएओ: साइटए को वापस भेजता है। उसके बाद ही ब्राउज़र आपकी स्क्रिप्ट को उन अनुरोधों का परिणाम प्राप्त करने देगा।

Answer 6

रिएक्ट और एक्सियोस का उपयोग करते हुए , यूआरएल के लिए प्रॉक्सी लिंक से जुड़ें और नीचे दिखाए अनुसार हेडर जोड़ें

https://cors-anywhere.herokuapp.com/ + Your API URL

बस प्रॉक्सी लिंक जोड़ने से काम चल जाएगा, लेकिन यह फिर से नो एक्सेस के लिए एरर भी फेंक सकता है। इसलिए शीर्ष लेख को जोड़ने के लिए बेहतर है जैसा कि नीचे दिखाया गया है।

axios.get(`https://cors-anywhere.herokuapp.com/[YOUR_API_URL]`,{headers: {'Access-Control-Allow-Origin': '*'}})
      .then(response => console.log(response:data);
  }

Comments

कृपया ऐसा न करें। प्रॉक्सी लिंक का उपयोग करना उपयोगकर्ता कुकीज़ को किसी मध्य-व्यक्ति को सौंपने के समान है। अवैध IMHO होना चाहिए

— anthonymonori

यह मेरे लिए उपयोगी था! * (जिसमें सुरक्षा संबंधी समस्याएं हैं) का उपयोग करने के बजाय, मैंने एक्सेस कंट्रोल को उस पते पर सटीक पते तक सीमित कर दिया है, जिसके साथ मैं सीख रहा हूं ... मेरे मामले में ' reqres.in/api/register '

— C-Note187

Answer 7

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

open -a Google\ Chrome --args --disable-web-security --user-data-dir

Answer 8

यदि आप PHP का उपयोग कर रहे हैं, तो php फ़ाइल की शुरुआत में निम्नलिखित कोड जोड़ने का प्रयास करें:

यदि आप लोकलहोस्ट का उपयोग कर रहे हैं, तो यह कोशिश करें:

header("Access-Control-Allow-Origin: *");

यदि आप सर्वर जैसे बाहरी डोमेन का उपयोग कर रहे हैं, तो यह प्रयास करें:

header("Access-Control-Allow-Origin: http://www.website.com");

Answer 9

मैं एक्सप्रेस 4 और नोड 7.4 और कोणीय के साथ काम करता हूं, मुझे एक ही समस्या थी जो मुझे इसकी मदद करती है:
ए) सर्वर साइड: फाइल ऐप में।जैसे कि मैं सभी प्रतिक्रिया के लिए हेडर देता हूं जैसे:

app.use(function(req, res, next) {  
      res.header('Access-Control-Allow-Origin', req.headers.origin);
      res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
      next();
 });  

यह सभी राउटर से पहले होना चाहिए ।
मैंने इस हेडर को बहुत जोड़ा है:

res.header("Access-Control-Allow-Headers","*");
res.header('Access-Control-Allow-Credentials', true);
res.header('Access-Control-Allow-Methods', 'GET,PUT,POST,DELETE');

लेकिन मुझे इसकी आवश्यकता नहीं है,
ख) ग्राहक पक्ष: ajax भेजने में आपको जोड़ने की आवश्यकता है: "withCredentials: true,"

$http({
     method: 'POST',
     url: 'url, 
     withCredentials: true,
     data : {}
   }).then(function(response){
        // code  
   }, function (response) {
         // code 
   });

सौभाग्य।

Comments

res.header('Access-Control-Allow-Origin', req.headers.origin);के रूप में ही हैres.header('Access-Control-Allow-Origin', '*');

— Aelfinn

Answer 10

क्रॉस ओरिजिन शेयरिंग के लिए, हेडर सेट करें: 'Access-Control-Allow-Origin':'*';

Php: header('Access-Control-Allow-Origin':'*');

नोड: app.use('Access-Control-Allow-Origin':'*');

यह विभिन्न डोमेन के लिए सामग्री साझा करने की अनुमति देगा।

Answer 11

पायथन में मैं बड़ी सफलता के साथ Flask-CORSपुस्तकालय का उपयोग कर रहा हूं । यह कोर के साथ सुपर आसान और दर्द रहित व्यवहार करता है। मैंने नीचे लाइब्रेरी के डॉक्यूमेंटेशन से कुछ कोड जोड़े हैं।

स्थापित कर रहा है:

$ pip install -U flask-cors

सरल उदाहरण जो सभी मार्गों पर सभी डोमेन के लिए CORS की अनुमति देता है:

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app)

@app.route("/")
def helloWorld():
  return "Hello, cross-origin-world!"

अधिक विशिष्ट उदाहरणों के लिए प्रलेखन देखें। मैंने ऊपर दिए गए सरल उदाहरण का उपयोग किया है मैं एक आयनिक एप्लिकेशन में कॉर्स मुद्दे के चारों ओर पाने के लिए जो मैं एक अलग फ्लास्क सर्वर का उपयोग कर रहा हूं।

Answer 12

अपने स्वयं के अनुभव से, यह एक सरल स्पष्टीकरण खोजना मुश्किल है कि कॉर्स यहां तक ​​कि एक चिंता का विषय क्यों है।

एक बार जब आप समझ जाते हैं कि यह क्यों है, हेडर और चर्चा बहुत स्पष्ट हो जाती है। मैं इसे कुछ लाइनों में एक शॉट देता हूँ।

---

यह सब कुकीज़ के बारे में है। कुकीज़ क्लाइंट पर उनके डोमेन द्वारा संग्रहीत की जाती हैं।

एक उदाहरण कहानी: आपके कंप्यूटर पर, के लिए एक कुकी है yourbank.com। हो सकता है कि आपका सत्र वहां हो।

मुख्य बिंदु: जब कोई क्लाइंट सर्वर से अनुरोध करता है, तो वह उस डोमेन के तहत संग्रहीत कुकीज़ भेज देगा जो क्लाइंट चालू है।

आप अपने ब्राउज़र पर लॉग इन हैं yourbank.com। आप अपने सभी खातों को देखने का अनुरोध करते हैं। yourbank.comकुकीज़ का ढेर प्राप्त करता है और अपनी प्रतिक्रिया (आपके खाते) को वापस भेजता है।

यदि कोई अन्य क्लाइंट किसी सर्वर से क्रॉस ओरिजिनल रिक्वेस्ट करता है, तो उन कुकीज़ को पहले की तरह ही भेजा जाता है। रूह रो।

आप ब्राउज़ करें malicious.com। दुर्भावनापूर्ण विभिन्न बैंकों के अनुरोधों का एक गुच्छा बनाता है, जिसमें शामिल हैं yourbank.com।

चूंकि कुकीज़ अपेक्षा के अनुसार मान्य हैं, इसलिए सर्वर प्रतिक्रिया को अधिकृत करेगा।

उन कुकीज़ को इकट्ठा किया जाता है और साथ भेजा जाता है - और अब, malicious.comसे एक प्रतिक्रिया है yourbank।

ओह।

---

तो अब, कुछ सवाल और जवाब स्पष्ट हो जाते हैं:

• "हम केवल ब्राउज़र को ऐसा करने से क्यों नहीं रोकते?" हां। CORS।
• "हम इसे कैसे प्राप्त कर सकते हैं?" क्या सर्वर ने अनुरोध किया है कि CORS ठीक है।

Answer 13

बस अपने web.config फ़ाइल में निम्न कोड पेस्ट करें।

उल्लेखनीय है कि, आपको <system.webServer>टैग के तहत निम्न कोड पेस्ट करना होगा

    <httpProtocol>  
    <customHeaders>  
     <add name="Access-Control-Allow-Origin" value="*" />  
     <add name="Access-Control-Allow-Headers" value="Content-Type" />  
     <add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS" />  
    </customHeaders>  
  </httpProtocol>  

Answer 14

एक्सेस-कंट्रोल-अनुमति-उत्पत्ति प्रतिक्रिया हेडर इंगित करता है कि क्या दिए गए मूल से अनुरोध कोड के साथ प्रतिक्रिया साझा की जा सकती है।

Header type Response       header
Forbidden header name      no

एक प्रतिक्रिया जो किसी संसाधन को एक्सेस करने के लिए किसी भी मूल से कोड की अनुमति देने के लिए ब्राउज़र को बताती है, उसमें निम्नलिखित शामिल होंगे:

Access-Control-Allow-Origin: *

अधिक जानकारी के लिए, यहाँ जाएँ ...।

Answer 15

Nginx और Appache

Apsillers उत्तर के अलावा, मैं विकी ग्राफ जोड़ना चाहूंगा जो दिखाता है कि अनुरोध सरल है या नहीं (और विकल्प पूर्व-उड़ान अनुरोध भेज रहा है या नहीं)

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

और यहां दो लोकप्रिय सर्वरों के लिए कॉन्फ़िगरेशन हैं

• कॉर्न्स को Nginx पर चालू करें ( nginx.confफ़ाइल)

  location ~ ^/index\.php(/|$) {
     ...
      add_header 'Access-Control-Allow-Origin' "$http_origin" always; # if you change "$http_origin" to "*" you shoud get same result - allow all domain to CORS (but better change it to your particular domain)
      add_header 'Access-Control-Allow-Credentials' 'true' always;
      if ($request_method = OPTIONS) {
          add_header 'Access-Control-Allow-Origin' "$http_origin"; # DO NOT remove THIS LINES (doubled with outside 'if' above)
          add_header 'Access-Control-Allow-Credentials' 'true';
          add_header 'Access-Control-Max-Age' 1728000; # cache preflight value for 20 days
          add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';  # arbitrary methods
          add_header 'Access-Control-Allow-Headers' 'My-First-Header,My-Second-Header,Authorization,Content-Type,Accept,Origin'; # arbitrary headers
          add_header 'Content-Length' 0;
          add_header 'Content-Type' 'text/plain charset=UTF-8';
          return 204;
      }
  }

• Appache पर CORS चालू करें ( .htaccessफ़ाइल)

  # ------------------------------------------------------------------------------
  # | Cross-domain Ajax requests                                                 |
  # ------------------------------------------------------------------------------
  
  # Enable cross-origin Ajax requests.
  # http://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity
  # http://enable-cors.org/
  
  # change * (allow any domain) below to your domain
  Header set Access-Control-Allow-Origin "*"
  Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
  Header always set Access-Control-Allow-Headers "My-First-Header,My-Second-Header,Authorization, content-type, csrf-token"
  Header always set Access-Control-Allow-Credentials "true"