2010-04-12 17 views
9

के साथ अपने डोमेन पर सुरक्षित लॉगिन हम एक बहुत बड़ी वेब आधारित सेवा प्रोजेक्ट शुरू कर रहे हैं। हम यह तय करने की कोशिश कर रहे हैं कि किस होस्टिंग पर्यावरण का उपयोग करना है। हम वास्तव में स्केलेबिलिटी कारणों के लिए Google App Engine का उपयोग करना चाहते हैं और स्वयं सर्वर से निपटने की आवश्यकता को खत्म करना चाहते हैं।Google App Engine

सुरक्षित लॉगिन/पंजीकरण हमारे लिए बहुत महत्वपूर्ण है, साथ ही अपने स्वयं के डोमेन का उपयोग कर रहा है। हमारे लक्षित दर्शक बहुत कंप्यूटर समझदार नहीं हैं। इस कारण से, हम नहीं चाहते हैं कि उपयोगकर्ताओं को ओपनआईडी के साथ साइन अप करना पड़े क्योंकि यह हमारी साइट के भीतर नहीं किया जा सकता है। हम अपने ग्राहकों को Google के साथ साइन अप करने के लिए मजबूर नहीं करना चाहते हैं।

जहां तक ​​मैं देख सकता हूँ, मैं भाग्य से बाहर हूँ। मैं इस सवाल का एक निश्चित उत्तर देने की उम्मीद कर रहा हूं। क्या लॉग इन (ओपनआईडी/Google) के लिए ग्राहकों को किसी अन्य साइट पर भेजने के बिना, हमारे डोमेन के माध्यम से हमारी साइट पर एन्क्रिप्टेड लॉगिन किया जा सकता है।

धन्यवाद।

+0

यह भी देखें: http://code.google.com/p/googleappengine/issues/detail?id=792 –

+0

आप किसी मौजूदा सत्र पुस्तकालय के साथ संयोजन के रूप में, अपने खुद के प्रवेश प्रणाली को लागू तो,। आपको वास्तव में मौजूदा पुस्तकालयों को नहीं मिलेगा जो सभी संभावनाओं में आपके लिए यह सब करते हैं, क्योंकि इसमें बहुत अधिक कस्टम काम शामिल है। –

उत्तर

3

Google अनुप्रयोग इंजन के साथ अपने स्वयं प्रमाणीकरण/पंजीकरण तंत्र बनाने से क्या रोक रहा कुछ भी नहीं है। एकमात्र समस्या यह है कि Google App Engine वर्तमान में केवल https://yourid.appspot.com के माध्यम से HTTPS का समर्थन करता है, न कि आपके Google Apps डोमेन (यानी https://www.foobar.com)। हालांकि, यह भविष्य में समर्थन के लिए उत्पाद roadmap पर है (तृतीय पक्ष डोमेन के लिए एसएसएल)। नोट, उत्पाद रोडमैप पर भी OAuth & ओपनआईडी के लिए अंतर्निहित समर्थन है।

अद्यतन: एक अन्य विकल्प एक प्रॉक्सी सर्वर (mod_proxy साथ अपाचे की तरह) का उपयोग करें और प्रॉक्सी सर्वर के लिए अपने डोमेन मैप करने के लिए और हो सकता है तो प्रॉक्सी सर्वर कर सकते हैं Google अनुप्रयोग इंजन प्रॉक्सी HTTP और HTTPS अनुरोध। अनुरोधों के पीछे appspot.com डोमेन पर अनुरोधों को प्रॉक्सी किया जा सकता है। मैंने वास्तव में ऐसा नहीं किया है, लेकिन मेरा मानना ​​है कि इसे काम करना चाहिए। हालांकि, यह आपको प्रॉक्सी सर्वर पर विफलता का एक बिंदु देगा जो मूल रूप से Google App Engine की उच्च-उपलब्धता और स्केलेबिलिटी के उद्देश्य को हरा देता है। यह निश्चित रूप से केवल एक अल्पकालिक समाधान होगा जब तक कि Google तृतीय-पक्ष डोमेन या ओपनआईडी के लिए SSL का समर्थन नहीं करता।

+0

हाँ, मुझे इस बारे में पता है, यही कारण है कि मैं एक और समाधान खोजने की उम्मीद कर रहा हूं। जहां तक ​​मुझे पता है, योजना टीएलएस एसएनआई को लागू करना है जो विंडोज एक्सपी (किसी भी ब्राउज़र) पर काम नहीं करती है, जो मेरी राय में एक सार्वजनिक साइट के लिए एक स्वीकार्य समाधान नहीं है जहां आप अपने ग्राहकों के वातावरण को नियंत्रित नहीं करते हैं। – mhost

+0

एक अन्य विकल्प जो आपके लिए काम कर सकता है या नहीं भी एक HTTP पृष्ठ से HTTPS URL पर पोस्ट करना है। इस तरह उपयोगकर्ता वास्तव में https://yourid.appspot.com डोमेन को तब तक नहीं देख पाएंगे जब तक कि वे HTML को न देख सकें। मुझे पता है कि यह एक हैक है, लेकिन यह कुछ परिदृश्यों के लिए पर्याप्त हो सकता है। –

+0

ओपनआईडी (उत्पाद रोडमैप पर) के लिए निर्मित समर्थन शायद अल्पावधि में टीएलएस एसएनआई की तुलना में बेहतर समाधान होगा। Windows XP के साथ अभी भी बहुत से लोग हैं जो उन उपयोगकर्ताओं का समर्थन नहीं करते हैं, मैं सहमत हूं। –

6

सबसे कठिन हिस्सा कुकी समस्या के समाधान हो रही है। जबकि आप https://yourdomain.appspot.com के विरुद्ध सुरक्षित और कस्टम लॉग इन कर सकते हैं, तो आप वहां एक कुकी सेट नहीं कर सकते हैं जो http://yourdomain.com पर काम करेगा।

जब आप में उपयोगकर्ता लॉग इन करने की जरूरत है, उन्हें https://yourdomain.appspot.com पर भेज दें:

यहाँ मैं क्या प्रस्ताव है। यदि वे क्रेडेंशियल्स को सही तरीके से दर्ज करते हैं, तो एक बार टोकन बनाएं और इसे डेटास्टोर में या मेमकेच में रखें। इसे कुछ सेकंड का जीवनकाल दें।

फिर उपयोगकर्ता को http://yourdomain.com/authenticate?token=mytoken पर स्पष्ट रूप से रीडायरेक्ट करें (स्पष्ट रूप से उचित नामों को प्रतिस्थापित करें), यह सुनिश्चित करने के लिए जांचें कि टोकन मान्य है और समाप्त नहीं हुआ है, और यदि सभी स्पष्ट हैं, तो उपयुक्त कुकीज़ सेट करें और टोकन की समय सीमा समाप्त करें।

मुझे लगता है कि ठीक काम करेंगे। आशा करता हूँ की ये काम करेगा!

+0

क्या यह आपको नहीं खोलेंगे प्रतिरूपण के लिए? यदि मैं मध्य हमले में एक आदमी चला रहा हूं तो मैं उपयोगकर्ता को टोकन का उपयोग करने से रोकता हूं और फिर इसे स्वयं उपयोग करता हूं। अब मैं उपयोगकर्ता के रूप में लॉग इन हूं और उपयोगकर्ता को फिर से लॉगिन करने का प्रयास करना होगा। – rhololkeolke

1

अपने खतरा मॉडल GAE के लिए "पिछले हॉप" पर एक गैर एन्क्रिप्टेड लिंक स्वीकार कर सकते हैं, इस पर निर्भर करता है, आप ब्राउज़र से एसएसएल को संभालने के लिए एक प्रॉक्सी का उपयोग कर सकते हैं। यहाँ एक विधिपत्र मैं CloudFlare का उपयोग करके SSL हमेशा चालू पाने के लिए पर लिखा है:

http://blorn.com/post/20185054195/ssl-for-your-domain-on-google-app-engine

इस संरचना की दृष्टि से जिस तरह से एसएसएल के अलावा कोई अलग से गूगल के लिए काम करेंगे नहीं है, यह सिर्फ इतना है कि Google द्वारा उपलब्ध कराए एसएसएल समाप्त कर देगा है इसके बाहर के बजाय जी के नेटवर्क के भीतर। यदि आप फायरशेप, क्लाउडफ्लेयर (या कोई अन्य एसएसएल प्रॉक्सी) के खिलाफ सुरक्षा करने की कोशिश कर रहे हैं तो ठीक होगा।यदि आप सीएफ और Google के बीच ट्रंक कनेक्शन पर स्नूप के बारे में चिंतित हैं, तो आप एक अधिक परिष्कृत समाधान चाहते हैं।