वेब खेत पर डॉटनेट ओपेनएथ

Question

मैं ओपनआईडी प्रदाता और एक भरोसेमंद पार्टी दोनों के लिए डॉटनेट ओपेनएथ लागू कर रहा हूं। दोनों स्थितियों में, सर्वर लोड बैलेंसर के पीछे हैं, इसलिए किसी भी HTTP अनुरोध के लिए, हम यह नहीं मान सकते कि हम एक ही सर्वर पर क्लिक करेंगे।

ऐसा लगता है कि लंबित अनुरोध कुंजी संग्रहीत करने के लिए DotNetOpenAuth depends on the Session। चूंकि सर्वर अनुरोधों के बीच बदल सकता है, हम मानक InProc सत्र पर निर्भर नहीं कर सकते हैं। दुर्भाग्यवश, हम सत्र के लिए स्टोर के रूप में सफलतापूर्वक एसक्यूएल लागू करने में असमर्थ रहे हैं।

मेरा प्रश्न है: क्या क्लाइंट कुकी के रूप में लंबित प्रमाणीकरण रिक्वेस्ट को स्टोर करना सुरक्षित है? सत्र का उपयोग करने से भी बदतर?

Answer 1

ProviderEndpoint.PendingAuthenticationRequest संपत्ति केवल आपकी सुविधा के लिए है, मुख्य रूप से सरल परिदृश्यों के लिए। यदि यह आपके लिए काम नहीं करता है, तो हर तरह से इसे एक और तरीके से स्टोर करें और पूरी तरह से इस संपत्ति को अनदेखा करें। वहां कोई नुकसान नहीं हुआ।

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

संक्षेप में, आप SQL स्टोर में उपयोगकर्ता सत्रों को स्टोर करना चुन सकते हैं या नहीं चुन सकते हैं। उसे ठीक होना चाहिए। मुझे लगता है कि जिस मुद्दे पर आप भाग गए थे (हमने ईमेल द्वारा चर्चा की थी) यह था कि आपको अपने IProviderApplicationStore को लागू करने की आवश्यकता है, जो आपके सभी वेब सर्वरों पर साझा किए गए डेटाबेस में नॉन और एसोसिएशन स्टोर करेगा। यह करना जरूरी है, और उपयोगकर्ता सत्र स्थिति के लिए ऑर्थोगोनल है क्योंकि यह एप्लिकेशन स्तर पर संग्रहीत है।