एक विकल्प अनुरोध क्यों भेजा गया है और क्या मैं इसे अक्षम कर सकता हूं?

Question

मैं एक वेब एपीआई का निर्माण कर रहा हूं। मैंने पाया कि जब भी मैं Chrome से POST का उपयोग करता हूं, तो अपने API को प्राप्त करता हूं, वास्तविक अनुरोध से पहले हमेशा एक विकल्प अनुरोध भेजा जाता है, जो काफी कष्टप्रद होता है। वर्तमान में मुझे किसी भी विकल्प के अनुरोध को अनदेखा करने के लिए सर्वर मिलता है। अब मेरा सवाल है कि सर्वर के लोड को दोगुना करने के लिए एक ऑप्शन रिक्वेस्ट भेजना क्या अच्छा है? क्या ब्राउज़र को विकल्प भेजने से पूरी तरह से रोकने का कोई तरीका है?

Answer 1

2018-09-13 को संपादित करें : इस प्री-फ़्लाइट रिक्वेस्ट के बारे में कुछ पूर्वधारणाएं जोड़ी गईं और इस रिपेप्शन के अंत में इससे कैसे बचा जाए।

OPTIONSअनुरोध वे होते हैं जिन्हें हम pre-flightअनुरोध कहते हैं Cross-origin resource sharing (CORS)।

जब आप विशिष्ट स्थितियों में विभिन्न उत्पत्ति के लिए अनुरोध कर रहे हों, तो वे आवश्यक हैं।

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

जब भी आप क्रॉस ओरिजिनल रिक्वेस्ट करने का प्रयास कर रहे हों, तो आपके सर्वर को अनदेखा नहीं करना चाहिए बल्कि इन अनुरोधों को संभालना चाहिए।

एक अच्छा संसाधन यहाँ पाया जा सकता है http://enable-cors.org/

आरामदायक पाने के लिए इन्हें संभालने का एक तरीका यह सुनिश्चित करना है कि किसी भी पथ के OPTIONSलिए सर्वर इस हेडर के साथ प्रतिक्रिया भेजता है

Access-Control-Allow-Origin: *

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

अपने सर्वर पर CORS समर्थन जोड़ने के तरीके के बारे में अधिक जानकारी के लिए निम्न फ़्लोचार्ट देखें

http://www.html5rocks.com/static/images/cors_server_flowchart.png

---

2018-09-13 को संपादित करें

MDS डॉक्सOPTIONS में बताए गए, केवल केस के मामलों में CORS अनुरोध को ट्रिगर किया गया है :

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

केवल अनुमत विधियाँ हैं:

• प्राप्त
• सिर
• पद

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

• स्वीकार करना
• स्वीकार करें-भाषा
• सामग्री-भाषा
• सामग्री-प्रकार (लेकिन नीचे दी गई अतिरिक्त आवश्यकताओं पर ध्यान दें)
• डीपीआर
• डाउनलिंक
• डेटा बचाना
• व्यूपोर्ट-चौड़ाई
• चौड़ाई

सामग्री-प्रकार हेडर के लिए केवल अनुमत मान हैं:

• आवेदन / x-www फार्म-urlencoded
• बहुखण्डीय / फार्म-डेटा
• पाठ / सादे

अनुरोध में उपयोग किए गए किसी भी XMLHttpRequestUpload ऑब्जेक्ट पर कोई ईवेंट श्रोता पंजीकृत नहीं हैं; इन्हें XMLHttpRequest.upload प्रॉपर्टी का उपयोग करके एक्सेस किया जाता है।

अनुरोध में कोई ReadableStream ऑब्जेक्ट का उपयोग नहीं किया जाता है।

Comments

लेकिन इस क्रोम ध्वज को सभी सामान्य उपयोगकर्ताओं के लिए सेट करना यथार्थवादी नहीं है।

— कियान चेन

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

— रॉबिन क्लॉवर्स

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

— रडार

यदि मैं curlएपी के लिए काम करता हूं तो यह कैसे होगा , लेकिन क्रोम से चलने पर मुझे त्रुटि मिलती है?

— SuperUberDuper

@SuperUberDuper क्योंकि कॉर्स और प्रीफ़्लाइट अनुरोध एक ब्राउज़र से संबंधित मामला है। आप Originअपने अनुरोध में एक शीर्ष लेख जोड़कर कॉर्स को अनुकरण कर सकते हैं जैसे कि अनुरोध एक विशिष्ट होस्ट (जैसे कि आपकाwebsite) से आ रहा था। आप हेडर अनुरोध के HTTP विधि OPTIONSऔर Access-Control-*हेडर के लिए प्रीफ़्लाइट अनुरोधों का अनुकरण भी कर सकते हैं

— लियो कोरे

Answer 2

इस मुद्दे के माध्यम से चले गए हैं, नीचे इस मुद्दे और मेरे समाधान के लिए मेरा निष्कर्ष है।

कॉर्स की रणनीति के अनुसार (आप इसके बारे में पढ़ने के लिए अत्यधिक अनुशंसा करते हैं) आप ब्राउज़र को विकल्प अनुरोध भेजने से रोकने के लिए मजबूर नहीं कर सकते हैं, अगर उसे लगता है कि उसे इसकी आवश्यकता है।

दो तरीके हैं जिनसे आप इसके आसपास काम कर सकते हैं:

1. सुनिश्चित करें कि आपका अनुरोध एक "सरल अनुरोध" है
2. Access-Control-Max-Ageविकल्प अनुरोध के लिए सेट करें

सरल अनुरोध

एक साधारण क्रॉस-साइट अनुरोध वह है जो निम्नलिखित सभी शर्तों को पूरा करता है:

केवल अनुमत विधियाँ हैं:

• प्राप्त
• सिर
• पद

उपयोगकर्ता एजेंट (जैसे कनेक्शन, उपयोगकर्ता-एजेंट, आदि) द्वारा स्वचालित रूप से सेट किए गए हेडर के अलावा, केवल हेडर जो मैन्युअल रूप से सेट होने की अनुमति है, वे हैं:

• स्वीकार करना
• स्वीकार करें-भाषा
• सामग्री-भाषा
• सामग्री प्रकार

सामग्री-प्रकार हेडर के लिए केवल अनुमत मान हैं:

• आवेदन / x-www फार्म-urlencoded
• बहुखण्डीय / फार्म-डेटा
• पाठ / सादे

एक साधारण अनुरोध पूर्व-उड़ान विकल्प अनुरोध का कारण नहीं होगा।

विकल्प की जांच के लिए एक कैश सेट करें

आप Access-Control-Max-Ageविकल्प अनुरोध के लिए सेट कर सकते हैं, ताकि जब तक यह समाप्त न हो जाए, तब तक यह अनुमति की दोबारा जांच नहीं करेगा।

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

सीमा नोट की गई

• क्रोम, के लिए अधिकतम सेकंड के लिए Access-Control-Max-Ageहै 600जो 10 मिनट है, के अनुसार क्रोम स्रोत कोड
• Access-Control-Max-Ageहर बार केवल एक संसाधन के लिए काम करता है, उदाहरण के लिए, GETएक ही URL पथ के साथ अनुरोध करता है , लेकिन विभिन्न प्रश्नों को अलग-अलग संसाधनों के रूप में माना जाएगा। तो दूसरे संसाधन के लिए अनुरोध अभी भी एक प्रीफ़्लाइट अनुरोध को ट्रिगर करेगा।

Comments

हाँ ... यह स्वीकार किया जाना चाहिए उत्तर और quesiton के लिए सबसे अधिक प्रासंगिक ..!

— राजेश एमबीएम

उल्लेख करने के लिए धन्यवाद Access-Control-Max-Age। यही यहाँ की कुंजी है। यह आपको अत्यधिक प्रीफ़लाइट अनुरोधों से बचने में मदद करता है।

— इदरीस मोख्तारज़ादा

मैं अनुरोध प्राप्त करने के लिए axios का उपयोग कर रहा हूं। मैं axios अनुरोध में एक्सेस-कंट्रोल-मैक्स-एज कहां सेट कर सकता हूं?

— मोहित शाह

+1 एक्सेस-कंट्रोल-मैक्स-एज हेडर यहाँ की कुंजी है। यह स्वीकृत उत्तर होना चाहिए! मैं हेडर पर 86400 सेकंड (24 घंटे) सेटअप करता हूं और प्रीफ्लेग का अनुरोध समाप्त हो गया है!

— 20

@VitalyZdanevich नहीं! application/jsonसिर्फ इसलिए नहीं बचें क्योंकि यह आपके अनुरोध को "सरल" बनाता है (और इस तरह कॉर्स को ट्रिगर करता है)। ब्राउज़र अपना काम कर रहा है। अपने सर्वर को किसी हेडर की तरह वापस करने के लिए सेट करें Access-Control-Max-Age: 86400और ब्राउज़र 24 घंटों के लिए विकल्प के अनुरोध को फिर से नहीं करेगा।

— colm.anseo

Answer 3

कृपया पूर्व-उड़ान विकल्प अनुरोध की वास्तविक आवश्यकता पर इस उत्तर को देखें: CORS - प्रीफ्लाइट अनुरोधों को शुरू करने के पीछे प्रेरणा क्या है?

विकल्प अनुरोध को अक्षम करने के लिए, नीचे दिए गए शर्तों को अजाक्स अनुरोध के लिए संतुष्ट होना चाहिए:

1. अनुरोध कस्टम HTTP हेडर जैसे 'एप्लिकेशन / xml' या 'एप्लिकेशन / json' आदि को सेट नहीं करता है
2. अनुरोध विधि को GET, HEAD या POST में से एक होना चाहिए। पोस्ट करते हैं, तो सामग्री प्रकार से एक होना चाहिए application/x-www-form-urlencoded, multipart/form-dataयाtext/plain

संदर्भ: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

Comments

"कस्टम HTTP हेडर" के लिए +1! मेरे मामले में, वे प्री-फ्लाइट अनुरोध को ट्रिगर करने का कारण बन रहे थे। मैंने हेडर में जो कुछ भी भेज रहा था उसे अनुरोध निकाय के रूप में भेजने का अनुरोध किया और विकल्प अनुरोधों को भेजना बंद कर दिया।

— आंद्रे

application/xmlया application/json"कस्टम HTTP हेडर" नहीं हैं। हेडर खुद होगा Content-Typeऔर उस हेडर को "कस्टम" कहकर गुमराह किया जाएगा।

— सिंह Correa

हटाए गए कस्टम HTTP हेडर और यह एक आकर्षण की तरह काम करता है!

— टिम डी

Answer 4

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

Comments

ओह मैं क्या सोच रहा हूँ घंटों तक डिबगिंग करना यह मेरा समाधान था। कंसोल डीबगिंग के कारण कैश अक्षम है।

— मोरिस

डिबग कंसोल बंद होने पर भी, प्रीफ़्लाइट अनुरोध भेजे जाते हैं

— Luca Perico

लुका: यह सच है लेकिन मुद्दा यह है कि "निष्क्रिय कैश" का कोई प्रभाव नहीं पड़ता है जब देव उपकरण बंद हो जाते हैं। प्रीफ़्लाइट अनुरोध केवल एक बार (कोर्स के प्रति सर्वर) भेजे जाते हैं यदि कैश अक्षम नहीं है और प्रत्येक अनुरोध से पहले भेजा जाता है यदि कैश अक्षम है।

— निर्

यह वास्तव में मददगार था।

— अनुराग पाटिल

Answer 5

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

यहां देखें: https://github.com/jpillora/xdomain

और काम करने का उदाहरण: http://jpillora.com/xdomain/

Comments

क्या यह वास्तव में ड्रॉप-इन प्रॉक्सी का एक प्रकार है?

— मटनस्टर

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

— क्वेंटिन 6

यहाँ समाधान एक iframe शिम पर भरोसा करता है जो कुछ मामलों में काम करता है, लेकिन कुछ प्रमुख सीमाएँ हैं। यदि आप प्रतिक्रिया की HTTP स्थिति कोड या किसी अन्य HTTP प्रतिक्रिया हेडर के मूल्य को जानना चाहते हैं तो क्या होगा?

— स्टीफन क्रॉस्बी

iFrames उसके लिए नहीं बने थे।

— रोमियो

यह एक सॉफ्टवेयर कार्यान्वयन है और अंतिम प्रश्न का उत्तर देता है: "क्या ब्राउज़र को विकल्प भेजने से पूरी तरह से रोकने का कोई तरीका है?" लंबी कहानी छोटी, इसे मोज़िला या क्रोमियम में अक्षम करने का कोई तरीका नहीं है, इसे कोड में लागू किया गया है और केवल "काम कर रहे" विकल्प व्यवहार को कम करते हैं।

— मेहतर

Answer 6

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

मैंने पाया कि आप एक मैक पर सफारी और क्रोम में कॉर्स को अक्षम कर सकते हैं।

Chrome में समान मूल नीति अक्षम करें

Chrome: Chrome से बाहर निकलें, एक टर्मिनल खोलें और इस कमांड को पेस्ट करें: open /Applications/Google\ Chrome.app --args --disable-web-security --user-data-dir

सफ़ारी: सफ़ारी में समान-मूल नीति को अक्षम करना

यदि आप सफारी पर समान-मूल नीति को अक्षम करना चाहते हैं (मेरे पास 9.1.1 है), तो आपको केवल डेवलपर मेनू को सक्षम करने की आवश्यकता है, और विकसित मेनू से "क्रॉस-उत्पत्ति प्रतिबंधों को अक्षम करें" चुनें।

Comments

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

— जांनि

काश वेब इस तरह से काम करता, तो हम बिना अतिरिक्त परेशानी के सर्वर से डेटा की जरूरत का अनुरोध कर सकते हैं।

— 15:48 बजे जेमिलोइ

Answer 7

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

Access-Control-Max-Ageहेडर के साथ अपने सर्वर का उत्तर दें और अनुरोधों के लिए जो उसी बिंदु पर जाएं प्रीफलाइट अनुरोध को कैश किया गया है और अब नहीं होगा।

Comments

इसके लिए शुक्रिया! तथ्य यह है कि OPTIONSअनुरोधों को इस हेडर के साथ कैश किया जाएगा जो मैंने पढ़ा है सभी कोर दस्तावेज में बहुत अपारदर्शी है।

— २३:२५ पर जोशरीरी

और कैश केवल उसी url के साथ प्रभावी होता है। मैं एक डोमेन-स्तर प्रीफ़्लाइट कैश चाहता हूं जो वास्तव में गोल यात्राओं को कम कर सकता है। (कोरस मूर्खतापूर्ण है!)

— आश्चर्य है कि

Answer 8

मैंने इस समस्या को हल कर दिया है।

if($_SERVER['REQUEST_METHOD'] == 'OPTIONS' && ENV == 'devel') {
    header('Access-Control-Allow-Origin: *');
    header('Access-Control-Allow-Headers: X-Requested-With');
    header("HTTP/1.1 200 OK");
    die();
}

यह केवल विकास के लिए है। इसके साथ मैं 9ms और 500ms इंतजार कर रहा हूं और 8s और 500ms नहीं। मैं ऐसा इसलिए कर सकता हूं क्योंकि उत्पादन जेएस ऐप उत्पादन के रूप में एक ही मशीन पर होगा इसलिए कोई OPTIONSविकास नहीं होगा लेकिन विकास मेरा स्थानीय है।

Answer 9

आप JSONP का उपयोग कर कोर से बच नहीं सकते।

Comments

आप केवल एक विकल्प अनुरोध प्राप्त करते हैं यदि आप कुछ सरल नहीं कर रहे हैं । आप JSONP के साथ केवल साधारण अनुरोध (GET, कोई कस्टम हेडर, कोई प्रमाणीकरण डेटा) नहीं बना सकते हैं, इसलिए JSONP यहां स्थानापन्न नहीं कर सकता है।

— क्वेंटिन

हां, मुझे पता है कि लेकिन मुझे परियोजना की आवश्यकताओं की जानकारी नहीं है। मुझे पता है कि यह कोई सरल नहीं है, लेकिन यह परियोजना से निर्भर करता है। सबसे खराब स्थिति में कॉर्स से बचने के लिए आपको मापदंडों का उपयोग करके डेटा पास करने की आवश्यकता होती है। इसलिए, JSONP प्रोजेक्ट आवश्यकताओं के अनुसार कॉर्स को बदल सकता है (जैसा कि आपने कहा, सरल अनुरोधों का उपयोग करके)

— जोस माटो

मैं तथाकथित पूर्व उड़ान के डिजाइन को नहीं समझता। यदि ग्राहक सर्वर पर डेटा भेजने का निर्णय लेता है, तो यह असुरक्षित होने का क्या कारण हो सकता है? मुझे नहीं लगता कि इससे तार पर भार को दोगुना करने का कोई मतलब है।

— कियान चेन

इस @ElgsQianChen शायद आपके प्रश्न का उत्तर कर सकते हैं stackoverflow.com/questions/15381105/...

— सिंह कोरिया

Answer 10

एक पूरे दिन बिताने के बाद और एक आधा इसी तरह की समस्या के माध्यम से काम करने की कोशिश में मैंने पाया कि यह IIS के साथ क्या करना था ।

मेरी वेब एपीआई परियोजना को इस प्रकार स्थापित किया गया था:

// WebApiConfig.cs
public static void Register(HttpConfiguration config)
{
    var cors = new EnableCorsAttribute("*", "*", "*");
    config.EnableCors(cors);
    //...
}

मेरे पास web.config> system.webServer नोड में CORS के विशिष्ट विन्यास विकल्प नहीं थे, जैसे मैंने कई पोस्टों में देखे हैं

Global.asax या नियंत्रक में डेकोरेटर के रूप में कोई कोर विशिष्ट कोड नहीं

समस्या थी ऐप पूल सेटिंग ।

प्रबंधित पाइपलाइन मोड क्लासिक (करने के लिए स्थापित किया गया था एकीकृत करने के लिए इसे बदल ) और पहचान नेटवर्क सेवा करने के लिए स्थापित किया गया था ( ApplicationPoolIdentity में बदल )

उन सेटिंग्स को बदलना (और ऐप पूल को रिफ्रेश करना) मेरे लिए इसे तय किया।

Answer 11

मेरे लिए जो काम किया गया था वह "github.com/gorilla/handlers" को आयात करना था और फिर इसे इस तरह से उपयोग करना था:

router := mux.NewRouter()
router.HandleFunc("/config", getConfig).Methods("GET")
router.HandleFunc("/config/emcServer", createEmcServers).Methods("POST")

headersOk := handlers.AllowedHeaders([]string{"X-Requested-With", "Content-Type"})
originsOk := handlers.AllowedOrigins([]string{"*"})
methodsOk := handlers.AllowedMethods([]string{"GET", "HEAD", "POST", "PUT", "OPTIONS"})

log.Fatal(http.ListenAndServe(":" + webServicePort, handlers.CORS(originsOk, headersOk, methodsOk)(router)))

जैसे ही मैंने एक अजाक्स पोस्ट अनुरोध को अंजाम दिया और JSON डेटा को इसमें संलग्न किया, क्रोम हमेशा कंटेंट-टाइप हेडर जोड़ देगा जो मेरे पिछले AllowedHeaders config में नहीं था।

Answer 12

एक समाधान जो मैंने पिछले समय में इस्तेमाल किया है - मान लीजिए कि आपकी साइट mydomain.com पर है, और आपको अग्रिंडोमेन.कॉम को ajax अनुरोध करने की आवश्यकता है

अपने डोमेन से विदेशी डोमेन में एक IIS फिर से कॉन्फ़िगर करें - जैसे

<rewrite>
  <rules>
    <rule name="ForeignRewrite" stopProcessing="true">
        <match url="^api/v1/(.*)$" />
        <action type="Rewrite" url="https://foreigndomain.com/{R:1}" />
    </rule>
  </rules>
</rewrite>

अपने mydomain.com साइट पर - फिर आप एक ही मूल अनुरोध कर सकते हैं, और किसी भी विकल्प के अनुरोध की कोई आवश्यकता नहीं है :)

Answer 13

यह प्रॉक्सी के उपयोग के मामले में हल किया जा सकता है जो अनुरोध को रोकते हैं और उपयुक्त हेडर लिखते हैं। वार्निश के विशेष मामले में ये नियम होंगे:

if (req.http.host == "CUSTOM_URL" ) {
set resp.http.Access-Control-Allow-Origin = "*";
if (req.method == "OPTIONS") {
   set resp.http.Access-Control-Max-Age = "1728000";
   set resp.http.Access-Control-Allow-Methods = "GET, POST, PUT, DELETE, PATCH, OPTIONS";
   set resp.http.Access-Control-Allow-Headers = "Authorization,Content-Type,Accept,Origin,User-Agent,DNT,Cache-Control,X-Mx-ReqToken,Keep-Alive,X-Requested-With,If-Modified-Since";
   set resp.http.Content-Length = "0";
   set resp.http.Content-Type = "text/plain charset=UTF-8";
   set resp.status = 204;
}

}

Answer 14

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

अगर मुझे कुछ समय मिल जाता है, तो मैं उसका परीक्षण करूंगा और इस पोस्ट को अपडेट करूंगा!

CSP: https://developer.mozilla.org/fr/docs/Web/HTTP/Headers/Content-Security-Policy

CSP विशिष्टता: https://www.w3.org/TR/CSP/

Comments

मैंने अभी-अभी परीक्षण किया है और यह काम नहीं करता है, XS अनुरोध प्रवेश के लिए CSP के बाद भी CORS की आवश्यकता है ...

— Arnaud Tournier