curl काम करता है, fetch विफल होता है: CORS और प्रीफ्लाइट का निदान
प्रतिक्रिया तक पहुँच को अनुरोध भेजने से अलग करें, OPTIONS प्रीफ्लाइट का निरीक्षण करें और प्रमाणित ब्राउज़र अनुरोधों के लिए स्पष्ट मूल स्थान कॉन्फ़िगर करें।
इस पृष्ठ पर
संक्षिप्त उत्तर
curl ब्राउज़र CORS नियमों को लागू नहीं करता है। इसलिए curl की सफल प्रतिक्रिया यह स्थापित नहीं करती कि किसी अन्य मूल स्थान पर जावास्क्रिप्ट उसे पढ़ सकता है। ब्राउज़र नेटवर्क पैनल का निरीक्षण करें: कुछ अनुरोध सीधे भेजे जाते हैं, जबकि JSON POST या Authorization वाले अनुरोध आमतौर पर OPTIONS प्रीफ्लाइट की आवश्यकता रखते हैं। प्रीफ्लाइट और वास्तविक प्रतिक्रिया दोनों की जाँच करें, पृष्ठ के सटीक मूल स्थान तथा लक्षित विधि और हेडर का उपयोग करके।
एक मूल स्थान एक योजना, होस्ट और पोर्ट है
https://app.example पर एक पृष्ठ और https://api.example पर एक API के अलग-अलग मूल स्थान होते हैं, भले ही उनके नाम में एक समान उपसर्ग हो। पोर्ट बदलना या HTTP से HTTPS पर स्विच करना भी मूल स्थान बदल सकता है। तैनाती के नाम से अनुमान लगाने के बजाय ब्राउज़र के वास्तविक Origin हेडर से शुरुआत करें।
CORS नियंत्रित करता है कि क्या एक ब्राउज़र क्रॉस-ओरिजिन प्रतिक्रिया को स्क्रिप्ट के लिए उजागर करता है। यह API प्रमाणीकरण नहीं है और यह curl या किसी अन्य सर्वर को API कॉल करने से नहीं रोकता। प्राधिकरण और अवांछित स्थिति बदलने वाले अनुरोधों से सुरक्षा को अनुप्रयोग में रखें।
सीधे अनुरोध और प्रीफ्लाइट अलग-अलग मार्ग हैं
GET जिसमें गैर-सुरक्षित सूचीबद्ध अनुरोध हेडर नहीं होते, अक्सर बिना प्रीफ्लाइट के भेजा जा सकता है। फॉर्म-अनुकूल सामग्री प्रकार का उपयोग करने वाले कुछ POST अनुरोध भी इस मार्ग का अनुसरण कर सकते हैं। फिर भी प्रतिक्रिया को पढ़ने से पहले उचित CORS हेडर की आवश्यकता होती है।
application/json, Authorization या PUT जैसी विधि का उपयोग करने वाले अनुरोध आमतौर पर प्रीफ्लाइट की आवश्यकता रखते हैं। ब्राउज़र अनुप्रयोग अनुरोध भेजने से पहले यह पूछता है कि कौन-सी विधि और अनुरोध हेडर अनुमत हैं। केवल प्रमाणपत्र होने का अर्थ यह नहीं है कि हर अनुरोध को प्रीफ्लाइट की आवश्यकता हो; पूर्ण अनुरोध स्थितियों का निरीक्षण करें।
एक विशिष्ट JSON POST उदाहरण
मान लें कि https://app.example पर एक पृष्ठ https://api.example/items पर एक bearer टोकन के साथ JSON POST भेजता है। ये उदाहरण होस्ट और काल्पनिक एंडपॉइंट हैं, कार्यात्मक सेवा नहीं। नीचे दिया गया कोड ब्राउज़र पृष्ठ में होना चाहिए; टोकन एक स्थानधारी है।
बिना मान्य कैश किए गए प्रीफ्लाइट परिणाम के, POST और प्राधिकरण तथा content-type हेडर को दर्शाते हुए OPTIONS अनुरोध की अपेक्षा करें। ब्राउज़र इन प्रीफ्लाइट हेडर का निर्माण करता है; अनुप्रयोग जावास्क्रिप्ट को उन्हें मैन्युअल रूप से सेट नहीं करना चाहिए।
fetch('https://api.example/items', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': 'Bearer DEMO_TOKEN'
},
body: JSON.stringify({name: 'sample'})
}).then(response => {
if (!response.ok) throw new Error('HTTP ' + response.status);
return response.json();
}).then(console.log).catch(console.error);सर्वर सेटिंग्स बदलने से पहले प्रीफ्लाइट पढ़ें
डेवलपर टूल्स में, नेटवर्क लॉग को संरक्षित करें और OPTIONS ढूंढें। इसका Origin पृष्ठ की पहचान करना चाहिए, और इस उदाहरण में Access-Control-Request-Method POST होना चाहिए। Access-Control-Request-Headers अनुरोधित गैर-सुरक्षित सूचीबद्ध हेडर सूचीबद्ध करता है। हेडर-नाम का मामला महत्वपूर्ण नहीं है।
उपयुक्त सफल प्रीफ्लाइट प्रतिक्रिया विशिष्ट मूल स्थान, विधि और हेडर की अनुमति देती है। OPTIONS को बाद के POST के लिए बनाए गए बीयरर टोकन की आवश्यकता नहीं होती, क्योंकि प्रीफ्लाइट उस अनुप्रयोग हेडर को नहीं ले जाता। वास्तविक अनुरोध पर प्रमाणीकरण आवश्यक बना रहता है।
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: authorization, content-type
Vary: Originवास्तविक प्रतिक्रिया के लिए अपनी अनुमति की आवश्यकता होती है
प्रीफ्लाइट को पार करना केवल पहला कदम है। POST प्रतिक्रिया में भी Access-Control-Allow-Origin की आवश्यकता होती है। त्रुटियों के साथ-साथ सफलता प्रतिक्रियाओं का भी निरीक्षण करें: उचित CORS हेडर के बिना प्रमाणीकरण विफलता JavaScript के लिए आम तौर पर जाल विफलता जैसी दिखाई देती है।
यदि OPTIONS सफल होता है लेकिन POST विफल होता है, तो उसकी स्थिति, एप्लिकेशन लॉग और प्रतिक्रिया हेडर का निरीक्षण करें। CORS संदेश यह साबित नहीं करता कि प्रमाणीकरण या एप्लिकेशन तर्क सफल हुआ। इसके विपरीत, सीधे भेजा गया अनुरोध सर्वर तक पहुँच सकता है भले ही ब्राउज़र उसकी प्रतिक्रिया तक स्क्रिप्ट की पहुँच को अवरुद्ध कर दे।
कुकीज़ के लिए स्पष्ट उत्पत्ति हैंडलिंग की आवश्यकता होती है
fetch के साथ क्रॉस-उत्पत्ति कुकीज़ भेजने के लिए credentials: include का उपयोग करें। सर्वर को क्रेडेंशियल्स की अनुमति देनी चाहिए और स्पष्ट अनुमत उत्पत्ति के साथ प्रतिक्रिया देनी चाहिए, Access-Control-Allow-Origin: * नहीं। ब्राउज़र कुकी नियम, जिसमें SameSite और तृतीय-पक्ष प्रतिबंध शामिल हैं, अभी भी लागू होते हैं।
आने वाली उत्पत्ति को प्रतिबिंबित करते समय एक अनुमति सूची बनाए रखें; हर उत्पत्ति को अंधाधुंध प्रतिध्वनित करने से बहुत व्यापक पहुँच प्रदान की जाती है। जब उत्पत्ति के अनुसार प्रतिक्रिया भिन्न होती है, तो Vary: Origin कैश को उन भिन्नताओं को अलग करने में मदद करता है। उत्पत्ति का ठीक से मिलान करें; पथ उत्पत्ति का हिस्सा नहीं होते।
ब्राउज़र अनुरोध की तुलना कमांड लाइन से करें
HTTP स्थिति और लौटे हुए हेडर का निरीक्षण करने में कमांड-लाइन कॉल मदद कर सकती है, लेकिन यह ब्राउज़र के प्रवर्तन को पुन: उत्पन्न नहीं करती। विधि, उत्पत्ति, अनुरोध हेडर, पुनर्निर्देश और क्रेडेंशियल्स हैंडलिंग की तुलना करें। एक सफल सादा GET, विफल हो रहे प्रमाणित JSON POST का निदान नहीं करता।
पठनीय API डेटा प्राप्त करने के लिए mode: no-cors का उपयोग न करें। इससे एक अपारदर्शी प्रतिक्रिया उत्पन्न हो सकती है जिसका बदन और स्थिति स्क्रिप्ट के लिए अनुपलब्ध होते हैं। अपारदर्शी परिणाम को सफल एकीकरण के रूप में मानने के बजाय इरादा किए गए अनुरोध के लिए सर्वर की अनुमति ठीक करें।
एक संक्षिप्त निदान क्रम
सबसे पहले पृष्ठ और API उत्पत्ति की पुष्टि करें। फिर सीधे अनुरोध को OPTIONS के बाद वास्तविक विधि से अलग करें। प्रीफ्लाइट पर अनुमत उत्पत्ति, विधि और हेडर की जाँच करें; एप्लिकेशन प्रतिक्रिया पर उत्पत्ति अनुमति की जाँच करें। अंत में प्रमाणीकरण और कुकी नीति का निरीक्षण करें।
प्रीफ्लाइट कैशिंग पहले दिखाई दिए OPTIONS अनुरोध को दबा सकती है। यह नहीं मान लें कि केवल इसलिए कि कोई नया OPTIONS प्रविष्टि नहीं दिखाई देता, अनुरोध सरल हो गया है। यह क्रम विफलता को एक विशिष्ट आदान-प्रदान तक सीमित करता है बिना API पहुँच नियंत्रण को कमजोर किए।
क्या जाँचें
- ब्राउज़र के सटीक Origin, विधि और अनुरोधित हेडर को रिकॉर्ड करें।
- त्रुटियों सहित OPTIONS और वास्तविक प्रतिक्रिया दोनों का निरीक्षण करें।
- प्रमाणित प्रतिक्रियाओं के लिए स्पष्ट अनुमत मूल स्थान का उपयोग करें।
- CORS से अलग प्रमाणीकरण और अनुरोध-धोखाधड़ी सुरक्षा रखें।
उपयोग की सीमाएँ
यह मार्गदर्शिका सामान्य fetch अनुरोधों को कवर करती है। पुनर्निर्देश, कुकी नीति, नेटवर्क विफलताएँ और अनुप्रयोग प्रमाणीकरण अतिरिक्त विफलताएँ उत्पन्न कर सकते हैं; CORS हेडर उन सभी को हल नहीं करते।