छवि कैशिंग, HttpHandler और FormsAuthentication

Question

सेटअप:

मैं एक वेबसाइट Formsauthentication कुकीज़ का उपयोग कर का उपयोग करता है लॉगिन टिकट स्टोर करने के लिए पर काम कर रहा हूँ। साइट पर HTTPHandler भी है जो डेटाबेस में संग्रहीत छवियों का प्रबंधन करता है। हैंडलर छवियों को सार्वजनिक रूप से कैश करता है और 20 मिनट में समाप्त हो जाता है। हमने देखा है कि चूंकि छवियों के पास एक पृष्ठ के समान जीवन चक्र है, इसलिए छवियों में Formsauthentication कुकी भी शामिल है। कॉन्फ़िगरेशन आईआईएस 6, विन 2 के सर्वर है, सामग्री समाप्ति सक्षम नहीं है।

समस्या:

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

क्या किसी ने इस व्यवहार के समान कुछ अनुभव किया है? यदि हां, तो क्या आप इस मुद्दे को लगातार पुन: उत्पन्न करने के बारे में कोई सलाह दे सकते हैं?

Answer 1

व्यक्ति बी को व्यक्ति ए की कुकी क्यों मिलती है? मुझे लगता है कि आपका मतलब है कि व्यक्ति बी की सत्र कुकी को ए के लॉगिन आईडी से जोड़ा जा रहा है। यह समस्या का केंद्र है।

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

मैं फ़ायरफ़ॉक्स एक्सटेंशन LiveHTTP इंस्टॉल करता हूं और अनुरोध/प्रतिक्रिया शीर्षलेखों की जांच करता हूं। मेरी शर्त है, आप देखेंगे कि ए और बी में अलग-अलग कुकीज़ हैं, लेकिन सर्वर पर वे दोनों एक ही लॉगिन आईडी से जुड़े हुए हैं।

Answer 2

हम मानते हैं कि कुकी प्रतिक्रिया हेडर में है और व्यक्ति ए की मशीन पर व्यक्ति की मशीन पर मौजूद एक ही कुकी लिख रही है। यह ध्यान रखना महत्वपूर्ण है कि यह समस्या आईई 7 में व्यक्ति ए और फ़ायरफ़ॉक्स में व्यक्ति बी के साथ हुई । साथ ही जब व्यक्ति ए लॉग आउट किया गया तो लॉग आउट किया गया व्यक्ति बी को भी लॉग आउट किया गया था क्योंकि फॉर्मस प्रमाणीकरण टिकट अब सर्वर पर मान्य नहीं था। तो हाँ उनके पास अलग-अलग कुकीज़ थीं लेकिन उनकी प्रत्येक कुकीज के भीतर समान फॉर्म प्रमाणीकरण टिकट था। हालांकि लॉग इन किए बिना उत्पन्न किया गया था।

हमें यह आलेख भी मिला लेकिन यह पुष्टि करने में सक्षम नहीं है कि यह कारण है या नहीं। http://support.microsoft.com/default.aspx?scid=kb;EN-US;917072

मैं देखता हूं कि LiveHTTP मुझे क्या बताता है और रिपोर्ट करेगा। धन्यवाद।

Answer 3

निश्चित रूप से, यदि उन छवियों (और सीएसएस और स्थिर जेएस फ़ाइलें, आदि ...) को HTTPS के रूप में नहीं दिया जा रहा है, तो वे आईएसपी या अन्य प्रॉक्सी (वास्तव में, कैश वास्तव में) द्वारा कैशिंग के अधीन होंगे उनकी कुकीज़ के साथ।

इस तरह एक कैशिंग निर्देश कुछ नहीं है:

Cache-control: no-cache="set-cookie,set-cookie2" 

... जो कैश "सेट-कुकी" प्रतिक्रिया हेडर कैश करने के लिए न करने के निर्देश माना जाता है, लेकिन मुझे यकीन है कि कैसे व्यापक रूप से इस समर्थित नहीं कर रहा हूँ है (मानक होने के बावजूद)।

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

Answer 4

क्षमा करें मैं यह उल्लेख करना भूल गया था कि सभी ट्रैफिक पोर्ट 443 के माध्यम से एसएसएल के रूप में जा रहा था। हम छवियों के लिए सेट कुकी को हटाने की योजना बना रहे हैं। हालांकि, हम उलझन में हैं कि एसएसएल के माध्यम से सभी ट्रैफिक संसाधित होने पर यह कैसे हो सकता है।

Answer 5

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

Answer 6

क्या आप सुनिश्चित हैं कि आपके पास पृष्ठ पर आउटपुट कैशिंग सक्षम नहीं है?

Answer 7

यह ऊपर निर्दिष्ट अनुसार आपके http अनुरोधों की जांच करने के लिए फिडलर स्थापित करने में मदद कर सकता है। साथ ही, कुकीज़ की पुष्टि करें वही हैं। क्या आपके हैंडलर, या प्रपत्र प्रमाणीकरण प्रणाली एक स्थिर वस्तु संदर्भ का उपयोग करते हैं? आपके कोड में दौड़ की स्थिति हो सकती है। और आपके संसाधनों को ठीक से लॉक नहीं कर रहे हैं।