मेरे पास एक साइट है, foo.com, जो bar.foo.com पर AJAX अनुरोध करता है। यह काम करेगा।AJAX, सबडोमेन, और एसएसएल
इसके अलावा, अगर foo एक सुरक्षित कनेक्शन है, https, bar.foo.com को https भी होना चाहिए? क्या ये दो साइटें विभिन्न प्रमाणपत्रों का उपयोग कर सकती हैं?
अधिकतर ब्राउज़र अपनी सुरक्षा/गोपनीयता सेटिंग के आधार पर, किसी भी बाहरी कॉल को अवरुद्ध करेंगे - और केवल उसी डोमेन पर AJAX कॉल किए जाने की अनुमति देंगे। यहां तक कि सबडोमेन अवरुद्ध हैं, क्योंकि साझा वातावरण पर वे वास्तविक खतरे पैदा कर सकते हैं।
संक्षेप में: केवल एक ही डोमेन के माध्यम से AJAX कॉल करें (शायद एक पृष्ठ पर कॉल करें, जो बदले में दूसरे डोमेन से कर्ल/फॉपेन/... के माध्यम से दूसरे पृष्ठ पर कॉल करता है), या आप परेशानियों में भाग लेंगे। यह आपके एसएसएल प्रश्न का भी उत्तर देता है - इससे कोई फर्क नहीं पड़ता कि आप किस एसएसएल का उपयोग कर रहे हैं, या फिर वे समान हैं - एसएसएल के बावजूद कॉल अवरुद्ध हो जाएंगे।
हां आप दोनों डोमेन के लिए अलग-अलग certs प्राप्त कर सकते हैं। यह सब कुछ है कि आप इसे कॉन्फ़िगर करने का निर्णय कैसे लेते हैं।
आप foo.com के लिए एक वेब सर्वर कॉन्फ़िगर कर सकते हैं और आप सुरक्षित और पोर्ट 443 के लिए पोर्ट 80 को सुरक्षित और उपयोग दोनों के लिए खोल सकते हैं।
आप bar.foo.com के लिए एक अलग वेब सर्वर कॉन्फ़िगर कर सकते हैं और उसी पोर्ट कॉन्फ़िगरेशन कर सकते हैं।
यदि आपको यह सुनिश्चित करने की आवश्यकता है कि आप दोनों पर सुरक्षित हैं तो आपको प्रत्येक अलग डोमेन के लिए कर्ट प्राप्त करने होंगे।
आप * .foo.com प्रमाण पत्र खरीदने में सक्षम हो सकते हैं जो आपको एक साइट को दूसरी साइट पर कॉपी करने और इसका उपयोग करने में सक्षम बनाता है।
भले ही आपका अनुरोध http://bar.foo.com से लिंक हो, भले ही आपके पास कोई सुरक्षित कनेक्शन न हो।
पोर्ट 443 का उपयोग करने के लिए वेबसर्वर को बताने के लिए आपके पास http "s" होना चाहिए और प्रमाण को सत्यापित करने का प्रयास करना है।
सभी कर्ट वास्तव में कहते हैं कि स्रोत विश्वसनीय है। भले ही यह भरोसा नहीं है और आप http "s" का उपयोग करते हैं और ब्राउज़र पर एक लॉक है जिसे आपका डेटा एन्क्रिप्ट किया गया है।
सादे-http AJAX के साथ: आप क्रॉस-डोमेन XMLHttpRequest करने के बारे में बात कर रहे हैं, जिसे ब्राउज़र द्वारा अनुमति नहीं है। भविष्य में एक सुरक्षित तरीके से इसे कार्यान्वित करने के लिए W3C proposal pending है (आंशिक रूप से आईई 8, आईआईआरसी द्वारा कार्यान्वित), लेकिन वर्तमान में यह निश्चित रूप से संभव नहीं है।
रहे हैं, तथापि, यह सुरक्षित रूप से करने के लिए समाधान: Subspace (जो iframes और document.domain उपयोग करता है), fragment identifier technique (फिर से, का उपयोग करता iframes) और window.name technique (फिर से, iframes!)।
जहां तक एसएसएल जाता है, आप डोमेन और सबडोमेन, या एक वाइल्डकार्ड (* .foo.com) प्रमाण के लिए अलग प्रमाणपत्र खरीद सकते हैं जो उन्हें कवर करता है (स्वाभाविक रूप से, वाइल्डकार्ड प्रमाण अधिक महंगा होगा)।
यदि आपके पास एक HTTPS पृष्ठ है जो अन्य डोमेन से आइटम्स का अनुरोध करता है, तो सब ठीक रहेगा जब तक कि सबकुछ HTTPS न हो। इसका अर्थ यह है कि यदि आप आईफ्रेम वर्कअराउंड्स में से किसी एक का उपयोग करते हैं, तो आपको आईफ्रेम की विशेषता में https:// स्कीम यूआरएल निर्दिष्ट करना होगा।
एक अंतिम, कम कुशल, वर्कअराउंड https://foo.com पर एक स्क्रिप्ट होना है जो प्रॉक्सी http://bar.foo.com असुरक्षित करने का अनुरोध करता है।(यह एक्सएचआर क्रॉस-डोमेन समस्या को भी हल करता है, इसलिए आप अन्य कामकाजों को अनदेखा कर सकते हैं।) बेशक, इसका मतलब है कि आप एक्सएचआर अनुरोध https://foo.com/someurl पर भेज रहे हैं, फिर यह http://bar.foo.com/someurl पर क्लिक कर रहा है, प्रतिक्रिया प्राप्त कर रहा है और इसे ब्राउज़र पर वापस भेज रहा है , तो प्रदर्शन के अनुसार आप foo.com पर bar.foo.com की सर्वर-साइड कार्यक्षमता को स्थानांतरित करने के लिए बहुत बेहतर हैं, यदि आपके पास वह विकल्प है। लेकिन अगर आप सर्वर स्क्रिप्ट नहीं ले जा सकते हैं, तो प्रॉक्सीइंग जाने का रास्ता है।
संपादित करें: मैं अलग HTTPS डोमेन के बीच काम करने के लिए कुछ अतिरिक्त परीक्षण कर और एक iframe AJAX के वैकल्पिक हल (#fragmentidentifier एक) प्राप्त करने के बाद पिछले 3 grafs बदल दिया है। आप कर सकते हैं एसएसएल क्रॉस-डोमेन AJAX iframes का उपयोग करते हुए जब तक कि सबकुछ https और https योजना आईफ्रेम src में उपयोग की जाती है। सारांश:
आप सह कर सकते हैं सुरक्षित क्रॉस-डोमेन अनुरोधों को पूरा करने के लिए एमबीएन जावास्क्रिप्ट टीएलएस और फ्लैश। इस प्रकार आपके आगंतुक https://foo.com पर जाते हैं और आप XmlHttpRequests को https://bar.foo.com पर बना सकते हैं। आप नियमित http के साथ एक ही काम कर सकते हैं।
आपको एक एसएसएल प्रमाण पत्र खरीदने की आवश्यकता होगी कि आपके आगंतुक के ब्राउज़र foo.com के लिए भरोसा करेंगे, लेकिन आप bar.foo.com, bar2.foo.com आदि के लिए अपना स्वयं का SSL प्रमाणपत्र जेनरेट कर सकते हैं। एक और महंगा विकल्प अपने स्वयं के एसएसएल प्रमाण पत्र (जो मुफ़्त है) उत्पन्न करने के लिए * .foo.com के लिए वाइल्डकार्ड एसएसएल प्रमाणपत्र खरीदना है। लेकिन अगर आप foo.com के माध्यम से उन साइटों पर क्रॉस-डोमेन अनुरोध कर रहे हैं तो आपको उस अतिरिक्त नकदी को खर्च करने की आवश्यकता नहीं है।
बाहर चेक ओपनसोर्स GitHub पर फोर्ज परियोजना:
http://github.com/digitalbazaar/forge/blob/master/README
अंत में ब्लॉग लिंक एक अधिक गहराई से स्पष्टीकरण प्रदान करते हैं।
हाँ आप निश्चित रूप से क्रॉस डोमेन AJAX सबमिट कर सकते हैं। हमने ssl.com wildcard cert का उपयोग करके सटीक एक ही सेटअप किया है लेकिन आप 2 साइटों पर 2 मानक Certs का उपयोग कर सकते हैं।
मूल रूप से आप JSONP (याहू, google, fb, आदि का उपयोग करेंगे) का उपयोग करेंगे। रिटर्न वैल्यू को फ़ंक्शन एएमडी में लपेटा जाता है जैसे
someFunction("{...}");