क्रॉस-ऑरिजिन रिसॉर्स को सुरक्षित तरीके से शेयर करना
ब्राउज़र की एक ही ऑरिजिन से जुड़ी नीति, किसी दूसरे ऑरिजिन से रिसॉर्स को पढ़ने से रोकती है. इस तरीके से, नुकसान पहुंचाने वाली साइटों को दूसरी साइटों का डेटा पढ़ने से रोका जाता है. हालांकि, इससे डेटा के सही इस्तेमाल को भी रोका जाता है.
आजकल के वेब ऐप्लिकेशन को अक्सर किसी दूसरे ऑरिजिन से रिसॉर्स चाहिए होते हैं. उदाहरण के लिए, किसी दूसरे डोमेन से JSON डेटा पाना या किसी दूसरी साइट से इमेज को <canvas> एलिमेंट में लोड करना. ये सार्वजनिक संसाधन हो सकते हैं, जिन्हें कोई भी पढ़ सकता है. हालांकि, एक ऑरिजिन से दूसरे ऑरिजिन के बीच नेटवर्क मैसेज भेजने से जुड़ी नीति के तहत, इनके इस्तेमाल पर रोक लगाई जाती है. डेवलपर, पहले से ही JSONP जैसे वर्कअराउंड का इस्तेमाल करते आ रहे हैं.
क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) इस समस्या को स्टैंडर्ड तरीके से ठीक करता है. सीओआरएस चालू करने पर, सर्वर ब्राउज़र को यह सूचना देता है कि वह किसी अन्य ऑरिजिन का इस्तेमाल कर सकता है.
वेब पर संसाधन का अनुरोध कैसे काम करता है?
ब्राउज़र और सर्वर, हाइपरटेक्स्ट ट्रांसफ़र प्रोटोकॉल (एचटीटीपी) का इस्तेमाल करके, नेटवर्क पर डेटा का आदान-प्रदान कर सकते हैं. एचटीटीपी, अनुरोध करने वाले और जवाब देने वाले के बीच कम्यूनिकेशन के नियमों को तय करता है. इसमें यह भी शामिल है कि किसी संसाधन को पाने के लिए कौनसी जानकारी ज़रूरी है.
एचटीटीपी हेडर, क्लाइंट और सर्वर के बीच मैसेज के आदान-प्रदान के लिए बातचीत करता है. इसका इस्तेमाल ऐक्सेस का पता लगाने के लिए किया जाता है. ब्राउज़र के अनुरोध और सर्वर के जवाब वाले मैसेज, दोनों को हेडर और मुख्य हिस्से में बांटा जाता है.
हेडर
मैसेज के बारे में जानकारी, जैसे कि मैसेज का टाइप या मैसेज की एन्कोडिंग. हेडर में, की-वैल्यू पेयर के तौर पर कई तरह की जानकारी शामिल की जा सकती है. अनुरोध के हेडर और जवाब के हेडर में अलग-अलग जानकारी होती है.
अनुरोध के हेडर का सैंपल
Accept: text/html
Cookie: Version=1
इस हेडर का मतलब है कि "मुझे जवाब में एचटीएमएल चाहिए. यह रही मेरे पास मौजूद कुकी."
रिस्पॉन्स हेडर का उदाहरण
Content-Encoding: gzip
Cache-Control: no-store
इस हेडर का मतलब है कि "इस रिस्पॉन्स में मौजूद डेटा को gzip का इस्तेमाल करके कोड में बदला गया है. इसे कैश न करें."
Body
मैसेज. यह सादा टेक्स्ट, इमेज बाइनरी, JSON, एचटीएमएल या कई अन्य फ़ॉर्मैट में हो सकता है.
CORS कैसे काम करता है?
एक ही ऑरिजिन की नीति, ब्राउज़र को क्रॉस-ऑरिजिन अनुरोधों को ब्लॉक करने के लिए कहती है. जब आपको किसी दूसरे ऑरिजिन से कोई सार्वजनिक संसाधन चाहिए होता है, तो संसाधन उपलब्ध कराने वाला सर्वर, ब्राउज़र को बताता है कि अनुरोध भेजने वाला ऑरिजिन, उसके संसाधन को ऐक्सेस कर सकता है. ब्राउज़र इस बात को याद रखता है और उस संसाधन के लिए क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग की अनुमति देता है.
पहला चरण: क्लाइंट (ब्राउज़र) का अनुरोध
जब ब्राउज़र किसी क्रॉस-ऑरिजिन का अनुरोध करता है, तो ब्राउज़र मौजूदा ऑरिजिन (स्कीम, होस्ट, और पोर्ट) के साथ एक Origin
हेडर जोड़ता है.
दूसरा चरण: सर्वर का रिस्पॉन्स
जब कोई सर्वर इस हेडर को देखता है और ऐक्सेस की अनुमति देना चाहता है, तो वह रिस्पॉन्स में Access-Control-Allow-Origin हेडर जोड़ता है. इसमें अनुरोध करने वाले ऑरिजिन (या किसी भी ऑरिजिन को अनुमति देने के लिए *) की जानकारी दी जाती है.
तीसरा चरण: ब्राउज़र को जवाब मिलता है
जब ब्राउज़र को सही Access-Control-Allow-Origin हेडर के साथ यह रिस्पॉन्स दिखता है, तो वह रिस्पॉन्स डेटा को क्लाइंट साइट के साथ शेयर करता है.
CORS के साथ क्रेडेंशियल शेयर करना
निजता की वजह से, सीओआरएस का इस्तेमाल आम तौर पर ऐसे अनुरोधों के लिए किया जाता है जिनमें अनुरोध करने वाले की पहचान नहीं होती. अगर आपको सीओआरएस का इस्तेमाल करते समय ऐसी कुकी भेजनी हैं जिनसे भेजने वाले की पहचान की जा सकती है, तो आपको अनुरोध और जवाब में अतिरिक्त हेडर जोड़ने होंगे.
अनुरोध
नीचे दिए गए उदाहरण की तरह, फ़ेच करने के विकल्पों में 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 हेडर भी शामिल हो सकता है. इससे प्रीफ़्लाइट के नतीजों को कैश मेमोरी में सेव करने की अवधि को सेकंड में तय किया जा सकता है. इससे क्लाइंट, प्रीफ़्लाइट अनुरोध को दोहराए बिना कई मुश्किल अनुरोध भेज सकता है.