वेब अनुप्रयोगों की बढ़ती संख्या (सबसे विशेष रूप से 37 सिग्नल 'बेसकैम्प) प्रत्येक उपयोगकर्ता/खाते में सबडोमेन असाइन करती है। मैं सोच रहा था कि इस तरह के दृष्टिकोण के पेशेवर और विपक्ष क्या हैं। क्या ऐसा करने का कोई विशेष कारण है या यह केवल कॉस्मेटिक फीचर है? क्या यह, उदाहरण के लिए, बेहतर/आसान स्केलेबिलिटी और बेहतर सुरक्षा की अनुमति देता है?वेब अनुप्रयोगों में सबडोमेन के पेशेवर/विपक्ष
मुझे लगता है कि यह वही मूल नीति से संबंधित हो सकता है। यदि दो उपयोगकर्ता के सदस्य पृष्ठ अलग-अलग सबडोमेन पर हैं, तो ब्राउज़र एक सबडोमेन से स्क्रिप्ट को किसी अन्य सबडोमेन में दस्तावेज़ों तक पहुंचने से रोक देगा। तो यदि मैलोरी एक साइट (mallory.example.org) पंजीकृत करता है और उस पर एक दुर्भावनापूर्ण स्क्रिप्ट डालता है, तो वह स्क्रिप्ट ऐलिस की साइट (alice.example.org) के DOM को संशोधित करने में सक्षम नहीं होगी। यदि वे इसके बजाय पथ का उपयोग कर रहे थे (example.org/mallory और example.org/alice), एसओपी काम नहीं करेगा, और मैलोरी की लिपि ऐलिस के पेज पर सभी प्रकार की बुरी चीजें कर सकती है, जैसे नकली लॉगिन स्क्रीन और पासवर्ड पोस्ट करना वापस मैलोरी।
यह एसओपी सुरक्षा तब भी काम करती है जब दोनों सबडोमेन एक ही आईपी को हल करते हैं - जब तक यूआरएल का होस्ट हिस्सा अलग होता है, आधुनिक ब्राउज़र क्रॉस-डोमेन स्क्रिप्टिंग प्रयासों (और कुछ अन्य संभावित खतरनाक चीजों) को अवरुद्ध करेंगे।
आपके इनपुट के लिए धन्यवाद। दूसरे शब्दों में, आप सुझाव देते हैं कि इसका एक निश्चित सुरक्षा लाभ है। –
हम इसे एकमात्र कारण से कर रहे हैं कि लोग अपने ब्रांड को देखना पसंद करते हैं। Conversion Support ग्राहक अपने नियंत्रण कक्ष के ब्रांडिंग के लिए सबडोमेन चुन सकते हैं और फिर इसे अपने लोगो और रंगों के साथ अनुकूलित कर सकते हैं।
सुरक्षा एक कारक नहीं है क्योंकि कोई भी स्क्रिप्ट नहीं रख सकता है। यह एक सौंदर्य विशेषता है।
मैं यह उल्लेख करना चाहता हूं कि दो पृष्ठों में संवाद हो सकता है यदि दोनों पृष्ठों में दस्तावेज़ है। डोमेन जावास्क्रिप्ट गुण डोमेन पर सेट है। उदाहरण के लिए:
document.domain = 'example.com';
इसका मतलब यह है एक ही मूल नीति a.example.com के लिए अक्षम है और b.example.com जब तक सभी उपडोमेन संपत्ति सेट के रूप में n.example.com करने के लिए।
आपके उत्तर के लिए धन्यवाद। यदि यह केवल एक कॉस्मेटिक फीचर है, तो क्या उपयोगकर्ता को अलग सबडोमेन वाले इंप्रेशन देने के लिए mod_rewrite का उपयोग करना आसान नहीं होगा? –
@bare_nature - यदि आप अपाचे का उपयोग कर रहे हैं, तो मुझे लगता है कि आप कर सकते हैं। लेकिन मान लीजिए कि आप जेटी का उपयोग कर रहे हैं? जेटी के पास एक रीराइट इंजन है, लेकिन यह 301 रीडायरेक्ट के लिए एप्लिकेशन स्तर पर एम्बेड किया गया है। मेरे मामले में एक स्प्रिंग फ़िल्टर या इंटरसेप्टर पूरी तरह से काम करता है, और हमें सबडोमेन के आधार पर प्रोग्रामेटिक रूप से विभिन्न कार्यों को करने की अनुमति देता है। इसके अलावा, पुनर्लेखन में अधिक प्रसंस्करण और कोई व्यावसायिक तर्क शामिल नहीं है। इसके अलावा, वे गतिशील नहीं हैं, आपको उन्हें हार्ड-कोड करना होगा। आपका ऐप कितना तेज़ होगा यदि * .example.com आपके ऐप पर तुरंत हल हो गया है? a.example.com, b.example.com, कोई अतिरिक्त प्रसंस्करण नहीं। – jmort253
प्रत्येक एप्लिकेशन के लिए सबडोमेन का उपयोग करने से यह जानने की मूल समस्या हल होती है कि कौन सा एप्लिकेशन उपयोग करना है। यह उपयोगकर्ता को एक ही ब्राउज़र में एक साथ कई एप्लिकेशन खोलने की अनुमति देता है।
एक अतिरिक्त लाभ यह है कि सबडोमेन में लॉगिन बाध्य करके उपयोगकर्ता को विभिन्न अनुप्रयोगों में एक अलग उपयोगकर्ता के रूप में लॉग इन किया जा सकता है। ऐप बी में लॉग इन करने के लिए ऐप ए से लॉग आउट करने की कोई आवश्यकता नहीं है। वह एक अलग लॉगिन के साथ दोनों में लॉग इन किया जा सकता है।
स्केलेबिलिटी के लिए लाभ आपके आर्किटेक्चर पर निर्भर करता है। आवेदन के अधिक साझा संसाधन (एक डेटाबेस) में, एप्लिकेशन को अलग करना अधिक कठिन है। दूसरी ओर, यदि आपके पास प्रत्येक एप्लिकेशन के लिए डेटाबेस है तो डेटाबेस का संस्करण बहुत अधिक परेशानी है। मुझे लगता है कि अधिकांश ऐप्स एक डेटाबेस और वर्चुअल सबडोमेन का उपयोग करते हैं। एक एकल आधार बनाए रखना आसान है (लेकिन स्केल करने में अधिक कठिन)।
सबडोमेन का उपयोग करने का नकारात्मक बिंदु यह है कि SSL के लिए आपको एक वाइल्डकार्ड प्रमाण पत्र की आवश्यकता होती है जो एक एकल डोमेन प्रमाणपत्र से अधिक लागत लेती है।
उत्तर के लिए धन्यवाद, Stefaan। मुझे लगता है कि आपने मेरे प्रश्न को गलत तरीके से पढ़ा है (या मैं पर्याप्त स्पष्ट नहीं था), लेकिन मैं विभिन्न उपयोगकर्ताओं के लिए सबडोमेन का उपयोग करने के बारे में सोच रहा हूं, अलग-अलग अनुप्रयोग नहीं। वैसे भी, आपकी अधिकांश तर्क किसी भी मामले में लागू होती है। यह भी जानना दिलचस्प है कि आप SSL प्रमाणपत्रों के बारे में क्या उल्लेख करते हैं। मैं नहीं जानता था कि। –
यह उपयोगी हो सकता है: http://myhosting.com/blog/2010/08/benefits-subdomains-ezinearticles/ –
धन्यवाद हैरी। हालांकि, आपके द्वारा उल्लिखित लिंक उपरोक्त के अधिक (पारंपरिक) पारंपरिक उपयोग के बारे में और विशेष रूप से वेब अनुप्रयोगों में सबडोमेन के गतिशील निर्माण के बारे में अधिक बात नहीं करता है। –