एएसपीनेट सत्र कुकी खो गई या हटा दी गई

Question

मेरे पास एक एएसपी.NET 2.0 साइट है जो सत्र में उपयोगकर्ता की आईडी संग्रहीत करती है ताकि यह इंगित किया जा सके कि वे लॉग इन हैं। कुछ स्थितियों में, उपयोगकर्ता लॉग इन रहने के लिए प्रतीत नहीं होता है। 've फ़िडलर में ट्रैफिक की निगरानी कर रहा है, और कुछ विवरण मैंने पाया:

• समस्या मेरा एक पुराने लैपटॉप पर 100% दोहराने योग्य जब IE7 और परियोजना प्रबंधक की लैपटॉप चल रहा है जब IE7 चल रहा है। यह समस्या कभी भी मेरे वर्तमान लैपटॉप पर आईई 7 चलाने या एफएफ चलाने के दौरान इनमें से किसी भी लैपटॉप पर नहीं होती है।
• समस्या केवल उत्पादन में होती है - विकास, आंतरिक स्टेजिंग या क्लाइंट स्टेजिंग पर नहीं। उत्पादन एकमात्र भार संतुलित वातावरण है, लेकिन ऊपर उल्लिखित दोहराने योग्यता मुझे कारक के रूप में संतुलित संतुलन बनाता है।
• जब पृष्ठ सेट करता है ("आईडी") = 1 क्लाइंट को प्रतिक्रिया भेजता है, तो मैं सभी मामलों में "सेट-कुकी" शीर्षलेख देख सकता हूं, जो ASP.Net_Session_Id कुकी बना रहा है (और यह केवल HttpOnly है)।
• सर्वर के बाद के अनुरोध उन मशीनों पर शीर्षलेख में उस कुकी को भेजेंगे जो समस्या का प्रदर्शन नहीं कर रहे हैं, लेकिन मशीनों पर नहीं, इसलिए या तो कुकी हटा दी जा रही है या "सेट-कुकी" हेडर को अनदेखा किया जा रहा है।
• कामों में लॉगिंग करने का तरीका निम्नानुसार है: www.DomainX.com पर एक पृष्ठ में एक आईफ्रेम है। उस iframe का स्रोत लॉगिन पर एक पेज है। DomainY.com। लॉगिन से कई प्रकार के पेज परोसते हैं। DomainY.com उपयोगकर्ता को लॉगिन/पंजीकरण प्रक्रिया के माध्यम से ले जाता है। Login.DomainY.com का अंतिम चरण www.DomainX.com पर किसी पृष्ठ पर रीडायरेक्ट करना है, जिसमें क्वेरीस्ट्रिंग में उपयोगकर्ता की आईडी शामिल है। Www.DomainX.com पर यह पृष्ठ आम तौर पर सत्र में आईडी संग्रहीत करता है, और उसके बाद शीर्ष जेएस दस्तावेज़ को नए पेज पर रीडायरेक्ट करने के लिए कुछ जेएस चलाता है, इस प्रकार उपयोगकर्ता को आईफ्रेम से बाहर ले जाता है। यह एक ऐसी प्रक्रिया है जिसने कई वर्षों तक डोमेनएक्स.com के कई मूल्यों के साथ काम किया है। यहां एक चीज जो अलग हो सकती है वह यह है कि इस मामले में, जेएस बस आईफ्रेम को नष्ट कर रहा है और कुछ में div है।
• परिदृश्यों के बीच एक और अंतर जो समस्या उत्पन्न होती है और जहां यह Google Analytics कुकीज़ में नहीं है। Login.DomainY.com/FinalStep.aspx आईफ्रेम के अंदर www.DomainX.com/SaveTheID.aspx पर रीडायरेक्ट करता है। जब समस्या नहीं होती है, तो SaveTheID.aspx के लिए अनुरोध में कई प्रकार की Google Analytics कुकीज़ (__utma, __utmz, आदि) शामिल हैं। जब समस्या होती है, तो इस अनुरोध में सभी GA कुकीज़ शामिल नहीं हैं (इसमें __utma, __utmz और __utmb गुम है)।
• उत्पादन ही एकमात्र वातावरण है जहां login.DomainY.com एसएसएल के तहत चलता है, इसलिए मैंने सोचा कि इससे संबंधित हो सकता है। लेकिन हम अस्थायी रूप से लॉगिन की हमारी स्टेजिंग प्रतिलिपि स्थापित करते हैं। DOMainY.com एसएसएल का उपयोग करने के लिए, और इसका कोई प्रभाव नहीं पड़ा।

कोई विचार क्या कारण हो सकता है?

संपादित करें: उत्पादन वातावरण में www.DomainX.com और DomainX.com के डोमेन हैं। कुकीज़ के साथ उन दोनों डोमेन के लिए सेट नहीं किया जा रहा एक और ज्ञात मुद्दा है। यह संभव है कि यह संबंधित है, लेकिन जब तक कि फिक्स प्रोडक्ट नहीं हो जाता तब तक मैं परीक्षण नहीं कर पाऊंगा।

Answer 1

आप अपने सत्र राज्य प्रदाता को यह देखने के लिए देखना चाहते हैं कि यह .NET एप्लिकेशन के दो सर्वर/उदाहरणों में काम करेगा या नहीं। यदि वे उदाहरण के लिए उदाहरण के लिए सेट हैं तो आप निश्चित रूप से इस समस्या में भाग लेंगे क्योंकि प्रत्येक सत्र उस धागे से बंधेगा जिस पर इसे बनाया गया था। इसके बजाय आप इसे एएसपीनेट राज्य सेवा में सार करना चाहते हैं, जो दोनों मशीनें एक्सेस कर सकती हैं या इससे भी बेहतर हो सकती हैं कि आपको एक वितरित कैशिंग समाधान जैसे कि माइक्रोसॉफ्ट वेग परियोजना का उपयोग करना चाहिए जो कि किसी भी मामले में दो मशीनों में सत्र वितरित करेगा।

इस से निपटने के कुछ अन्य तरीके लोड बैलेंसर (अनुशंसित नहीं) पर चिपचिपा सत्रों का उपयोग करना या कुकी-कम सत्र में जाना है जो काम करेगा लेकिन आपके कोड में कुछ सिरदर्द हो सकता है।

हमारे व्यापार में हमारे पास एक वितरित कैश वाला प्राथमिक और द्वितीयक सर्वर है जिससे कि यदि कोई मशीन नीचे जाती है तो दूसरे को ले जाया जा सकता है। यह वही सिद्धांत भार संतुलन पर लागू होता है और एक बार जब आप एक से अधिक मशीन या एप्लिकेशन पूल में एक से अधिक उदाहरण शुरू करते हैं तो आपको इसके लिए कोड करना होगा।

यदि आप सत्र के लिए वेग का उपयोग करते हैं तो सुनिश्चित करें कि आपके सत्रों को संग्रहीत करने के लिए आपके द्वारा चुने गए कैश को बेकार नहीं किया जा सकता है।

Answer 2

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

बीटीडब्लू: चिपचिपा सत्र खराब हैं क्योंकि इस पर होने वाले सत्र अनावश्यकता से सुरक्षित नहीं हैं। इसके अतिरिक्त, लोड बैलेंसर कम से कम लोड किए गए सर्वर को समय पर एक निश्चित बिंदु पर वितरित नहीं कर सकता है, यह केवल एक सत्र की शुरुआत में ही निर्णय ले सकता है और उसके बाद उपयोगकर्ता को वह रख सकता है जहां वह है।

यदि यह पता चला है कि आपके पास लोड बैलेंसर समस्या है, तो पहली बात यह है कि मैं सत्र चिपचिपाहट चालू कर दूंगा, और फिर एक कामकाजी उत्पादन वातावरण के सुखदायक बैकग्राउंग के साथ एक और समाधान की तलाश कर सकता हूं।

Answer 3

शूट, मैं अपने कुकी और उत्तर और संपादित करने की क्षमता खो दिया है ... चाहिए

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

हमारे पास एक अलग राज्य सर्वर चल रहा है, और यह वही है जिसका उपयोग उसी सर्वर द्वारा होस्ट की गई अन्य साइटों पर कुछ वर्षों के लिए किया गया है। समस्याओं के बिना जरूरी नहीं, लेकिन इस तरह की समस्या के बिना।

एक बैंड सहायता के रूप में, मैं वर्तमान में अन्य हठ तंत्र का परीक्षण कर रहा हूँ ...