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