मेरा दृष्टिकोण एक डोमेन को 'केंद्रीय' डोमेन और किसी अन्य को 'उपग्रह' डोमेन के रूप में नामित करता है।
जब कोई 'साइन इन' लिंक (या एक सतत लॉगिन कुकी प्रस्तुत करता है) पर क्लिक करता है, तो साइन इन फॉर्म आखिरकार केंद्रीय डेटा पर एक यूआरएल को भेजता है, जिसमें एक छिपी हुई फॉर्म तत्व के साथ यह कहता है कि कौन सा डोमेन से आया (बस सुविधा के लिए, इसलिए उपयोगकर्ता को बाद में रीडायरेक्ट किया जाता है)।
केंद्रीय पृष्ठ पर यह पृष्ठ एक सत्र कुकी (यदि लॉगिन अच्छी तरह से चला गया) सेट करने के लिए आगे बढ़ता है और यूआरएल में विशेष रूप से जेनरेट किए गए टोकन के साथ उस सत्र के लिए अद्वितीय है, जो उपयोगकर्ता द्वारा लॉग इन किया गया डोमेन पर रीडायरेक्ट करता है ।
उपग्रह यूआरएल का पृष्ठ तब टोकन को यह देखने के लिए जांचता है कि यह सत्र के लिए जेनरेट किए गए टोकन के अनुरूप है या नहीं, और यदि ऐसा है, तो यह टोकन के बिना खुद को रीडायरेक्ट करता है, और एक स्थानीय कुकी सेट करता है। अब उस उपग्रह डोमेन में सत्र कुकी भी है। यह रीडायरेक्ट यूआरएल से टोकन को साफ़ करता है, ताकि यह असंभव है कि उपयोगकर्ता या कोई क्रॉलर उस टोकन वाले यूआरएल को रिकॉर्ड करेगा (हालांकि अगर उन्होंने किया, तो इससे कोई फर्क नहीं पड़ता, टोकन एक-प्रयोग टोकन हो सकता है)।
अब, उपयोगकर्ता के पास केंद्रीय डोमेन और उपग्रह डोमेन दोनों में एक सत्र कुकी है। लेकिन क्या होगा यदि वे किसी अन्य उपग्रह की यात्रा करें? खैर, आम तौर पर, वे उपग्रह को अनधिकृत के रूप में दिखाई देंगे।
हालांकि, मेरे आवेदन के दौरान, जब भी कोई उपयोगकर्ता वैध सत्र में होता है, तो अन्य सैटेलाइट डोमेन पर पृष्ठों के सभी लिंक में एक या & एस शामिल होता है। मैं इस क्वेरी की स्ट्रिंग को "केंद्रीय सर्वर से जांचने के लिए आरक्षित करता हूं क्योंकि हम मानते हैं कि इस उपयोगकर्ता के पास सत्र है"। यही है, किसी भी एचटीएमएल पेज पर कोई टोकन या सत्र आईडी नहीं दिखाया जाता है, केवल अक्षर 'जो किसी की पहचान नहीं कर सकता है।
ऐसे यूआरएल को प्राप्त करने वाला यूआरएल, यदि कोई वैध सत्र अभी तक नहीं है, तो केंद्रीय डोमेन पर रीडायरेक्ट करें, "क्या आप मुझे बता सकते हैं कि यह कौन है?" क्वेरी स्ट्रिंग में कुछ डालने से।
जब उपयोगकर्ता केंद्रीय सर्वर पर आता है, यदि वे प्रमाणीकृत हैं तो केंद्रीय सर्वर को बस अपनी सत्र कुकी प्राप्त होगी। इसके बाद उपयोगकर्ता को उपग्रह को एक और एकल उपयोग टोकन के साथ भेज दिया जाएगा, जो सैटेलाइट के रूप में उपग्रह के रूप में व्यवहार करेगा, ऊपर लॉग इन करने के बाद (ऊपर देखें)। हां, उपग्रह अब उस डोमेन पर एक सत्र कुकी स्थापित करेगा, और क्वेरी स्ट्रिंग से टोकन को हटाने के लिए खुद को रीडायरेक्ट करेगा।
मेरा समाधान स्क्रिप्ट के बिना काम करता है, या iframe समर्थन। इसे किसी भी क्रॉस-डोमेन यूआरएल में जोड़ने के लिए '? S' की आवश्यकता होती है जहां उपयोगकर्ता के पास उस यूआरएल पर अभी तक कुकी नहीं हो सकती है। मैंने इस बारे में सोचने के तरीके के बारे में सोचा था: जब उपयोगकर्ता पहले लॉग इन करता है, तो प्रत्येक डोमेन पर रीडायरेक्ट की एक श्रृंखला सेट अप करें, प्रत्येक पर एक सत्र कुकी सेट करें। एकमात्र कारण मैंने इसे लागू नहीं किया है कि यह जटिल होगा कि आपको एक सेट ऑर्डर करने में सक्षम होना होगा कि ये रीडायरेक्ट कब और कब रुकेंगे, और आपको 15 डोमेन से आगे बढ़ने से रोक देगा (बहुत अधिक और आप खतरनाक रूप से कई ब्राउज़रों और प्रॉक्सी की 'रीडायरेक्ट सीमा' के करीब हो जाते हैं)।
यह oauth2 के समान है। आपने इसके शीर्ष पर स्वचालित लॉगिन स्तर दिया है, यदि आपके पास सभी ऐप्स हैं तो यह एक अच्छा विकल्प है। – matthuhiggins
अच्छा जवाब, लेकिन मेरे पास आपके उत्तर पर कुछ विचार हैं: 1) आपको सैटेलाइट यूआरएल को रिटर्न के रूप में पास करने की आवश्यकता नहीं है, आप इसके लिए http हेडर यूआरएल-रेफरर का उपयोग कर सकते हैं। 2) आपका रिटर्न टोकन असुरक्षित है, भले ही यह एकमात्र उपयोग टोकन है, भले ही हमलावर रिटर्न पोस्टबैक को रोक सके और सत्यापन पूर्ण होने से पहले कॉलर ऐप के बाहर टोकन का उपयोग कर सके, सही दृष्टिकोण दास पर एक सुरक्षित कोड उत्पन्न करता है और सत्यापित करता है केंद्रीय डोमेन पर इस कोड के साथ टोकन, टोकन सार्वजनिक है लेकिन सुरक्षित कोड के बिना हमलावर के लिए बेकार है। –
3) यदि आप राज्य-पूर्ण सर्वर (स्मृति या डीबी पर संग्रहीत उपयोगकर्ता जानकारी) का उपयोग करते हैं, तो आपको पहले लॉगिन की जांच करने के लिए यूआरएल बदलने की आवश्यकता नहीं है, क्योंकि हमलावर क्लाइंट पक्ष पर यूआरएल बदल सकता है, चेक जरूरी है यूआरएल पर पूछे बिना भी, हर अनुरोध पर किया जाना चाहिए। इसलिए जब कोई उपयोगकर्ता किसी भी सुरक्षित यूआरएल का अनुरोध करता है, तो आप जांचते हैं कि उपयोगकर्ता प्रमाणित था (स्मृति पर उपयोगकर्ता जानकारी) और यदि प्रमाणीकरण अभी भी वैध है (लॉगिन के x घंटे बाद) यदि नहीं, तो आप उसे फिर से लॉगिन सर्वर पर रीडायरेक्ट करते हैं। –