पब्लिश होने की तारीख: 5 नवंबर, 2018
ब्राउज़र की सेम-ऑरिजिन नीति, किसी दूसरे ऑरिजिन के संसाधन को पढ़ने से रोकती है. इस नीति की मदद से, नुकसान पहुंचाने वाली साइटों को दूसरी साइटों का डेटा पढ़ने से रोका जाता है. हालांकि, इससे सही इस्तेमाल भी रुक जाते हैं.
मॉडर्न वेब ऐप्लिकेशन अक्सर किसी दूसरे ऑरिजिन से संसाधन पाना चाहते हैं. उदाहरण के लिए, किसी दूसरे डोमेन से JSON डेटा पाना या किसी दूसरी साइट से इमेज लोड करना <canvas> एलिमेंट में. ये सार्वजनिक संसाधन हो सकते हैं, जिन्हें कोई भी पढ़ सकता है. हालांकि, सेम-ऑरिजिन नीति की वजह से, इनका इस्तेमाल नहीं किया जा सकता. डेवलपर,
JSONP जैसे वर्कअराउंड का इस्तेमाल करते रहे हैं.
क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) इस समस्या को स्टैंडर्ड तरीके से ठीक करता है. सीओआरएस की सुविधा चालू करने पर, सर्वर ब्राउज़र को बताता है कि वह किसी दूसरे ऑरिजिन का इस्तेमाल कर सकता है.
वेब पर संसाधन के लिए अनुरोध कैसे काम करता है?
हाइपरटेक्स्ट ट्रांसफ़र प्रोटोकॉल (एचटीटीपी) का इस्तेमाल करके, ब्राउज़र और सर्वर नेटवर्क पर डेटा का आदान-प्रदान कर सकते हैं. एचटीटीपी, अनुरोध करने वाले और जवाब देने वाले के बीच कम्यूनिकेशन के नियम तय करता है. इसमें यह भी शामिल है कि किसी संसाधन को पाने के लिए, किस जानकारी की ज़रूरत होती है.
एचटीटीपी हेडर, क्लाइंट और सर्वर के बीच मैसेज के आदान-प्रदान को मैनेज करता है. इसका इस्तेमाल, ऐक्सेस तय करने के लिए किया जाता है. ब्राउज़र के अनुरोध और सर्वर के रिस्पॉन्स, दोनों को हेडर और बॉडी में बांटा जाता है.
हेडर
मैसेज के बारे में जानकारी, जैसे कि मैसेज का टाइप या मैसेज की एन्कोडिंग. हेडर में, की-वैल्यू पेयर के तौर पर कई तरह की जानकारी शामिल हो सकती है. अनुरोध के हेडर और रिस्पॉन्स हेडर में अलग-अलग जानकारी होती है.
अनुरोध के हेडर का उदाहरण
Accept: text/html
Cookie: Version=1
इस हेडर का मतलब है कि "मुझे रिस्पॉन्स में एचटीएमएल चाहिए. मेरे पास यह कुकी है."
रिस्पॉन्स हेडर का उदाहरण
Content-Encoding: gzip
Cache-Control: no-store
इस हेडर का मतलब है कि "इस रिस्पॉन्स में मौजूद डेटा को gzip से एन्कोड किया गया है. इसे कैश न करें."
Body
मैसेज का मुख्य हिस्सा. यह सामान्य टेक्स्ट, इमेज बाइनरी, JSON, एचटीएमएल या कई अन्य फ़ॉर्मैट में हो सकता है.
सीओआरएस कैसे काम करता है?
सेम-ऑरिजिन नीति, ब्राउज़र को क्रॉस-ऑरिजिन अनुरोधों को ब्लॉक करने के लिए कहती है. जब आपको किसी दूसरे ऑरिजिन से कोई सार्वजनिक संसाधन चाहिए, तो संसाधन उपलब्ध कराने वाला सर्वर, ब्राउज़र को बताता है कि अनुरोध भेजने वाला ऑरिजिन, उसके संसाधन को ऐक्सेस कर सकता है. ब्राउज़र इसे याद रखता है और उस संसाधन के लिए क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग की अनुमति देता है.
पहला चरण: क्लाइंट (ब्राउज़र) का अनुरोध
जब ब्राउज़र, क्रॉस-ऑरिजिन अनुरोध करता है, तो ब्राउज़र, मौजूदा ऑरिजिन (स्कीम, होस्ट, और पोर्ट) के साथ एक Origin हेडर जोड़ता है.
दूसरा चरण: सर्वर का रिस्पॉन्स
जब सर्वर को यह हेडर दिखता है और वह ऐक्सेस की अनुमति देना चाहता है, तो वह रिस्पॉन्स में एक Access-Control-Allow-Origin हेडर जोड़ता है. इसमें अनुरोध करने वाले ऑरिजिन (या किसी भी ऑरिजिन को अनुमति देने के लिए *) की जानकारी होती है.
तीसरा चरण: ब्राउज़र को रिस्पॉन्स मिलता है
जब ब्राउज़र को सही Access-Control-Allow-Origin हेडर के साथ यह रिस्पॉन्स दिखता है, तो वह रिस्पॉन्स के डेटा को क्लाइंट साइट के साथ शेयर करता है.
सीओआरएस के साथ क्रेडेंशियल शेयर करना
निजता की वजह से, सीओआरएस का इस्तेमाल आम तौर पर गुमनाम अनुरोधों के लिए किया जाता है. इनमें अनुरोध करने वाले की पहचान नहीं की जाती. अगर आपको सीओआरएस का इस्तेमाल करते समय कुकी भेजनी हैं, तो आपको अनुरोध और रिस्पॉन्स में अतिरिक्त हेडर जोड़ने होंगे. कुकी की मदद से, भेजने वाले की पहचान की जा सकती है.
अनुरोध
fetch के विकल्पों में credentials: 'include' जोड़ें. जैसे, यहां दिए गए उदाहरण में.
इससे अनुरोध में कुकी शामिल हो जाती है. जैसे:
fetch('https://example.com', {
mode: 'cors',
credentials: 'include'
})
जवाब
Access-Control-Allow-Origin को किसी खास ऑरिजिन पर सेट करना ज़रूरी है. इसमें वाइल्डकार्ड के तौर पर * का इस्तेमाल नहीं किया जा सकता. साथ ही, Access-Control-Allow-Credentials को true पर सेट करना ज़रूरी है.
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
कॉम्प्लेक्स एचटीटीपी कॉल के लिए प्रीफ़्लाइट अनुरोध
जब कोई वेब ऐप्लिकेशन, कॉम्प्लेक्स एचटीटीपी अनुरोध करता है, तो ब्राउज़र, अनुरोध चेन की शुरुआत में एक प्रीफ़्लाइट अनुरोध जोड़ता है.
सीओआरएस की खास जानकारी में, कॉम्प्लेक्स अनुरोध को इस तरह से परिभाषित किया गया है:
- ऐसा अनुरोध जिसमें GET, POST या HEAD के अलावा अन्य तरीकों का इस्तेमाल किया जाता है.
- ऐसा अनुरोध जिसमें
Accept,Accept-LanguageयाContent-Languageके अलावा अन्य हेडर शामिल होते हैं. - ऐसा अनुरोध जिसमें
Content-Typeहेडर,application/x-www-form-urlencoded,multipart/form-dataयाtext/plainके अलावा कोई और होता है.
ब्राउज़र, ज़रूरी प्रीफ़्लाइट अनुरोध अपने-आप बनाता है और उन्हें अनुरोध के असली मैसेज से पहले भेजता है. प्रीफ़्लाइट अनुरोध, OPTIONS अनुरोध होता है. जैसे, यहां दिए गए उदाहरण में:
OPTIONS /data HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: DELETE
सर्वर साइड पर, अनुरोध पाने वाला ऐप्लिकेशन, प्रीफ़्लाइट अनुरोध का जवाब देता है. इसमें उन तरीकों के बारे में जानकारी होती है जिन्हें ऐप्लिकेशन, इस ऑरिजिन से स्वीकार करता है:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, DELETE, HEAD, OPTIONS
सर्वर के रिस्पॉन्स में, Access-Control-Max-Age हेडर भी शामिल हो सकता है. इससे, प्रीफ़्लाइट के नतीजों को कैश करने की अवधि सेकंड में तय की जा सकती है. इससे क्लाइंट, प्रीफ़्लाइट अनुरोध को दोहराए बिना, कई कॉम्प्लेक्स अनुरोध भेज सकता है.