वसंत सुरक्षा/जेएसएफ/हाइबरनेट दुर्घटनाग्रस्त सत्र टॉमकैट पर अपहरण?

Question

दूसरे दिन मेरे साथ कुछ अजीब और शर्मनाक हुआ और मेरे पास यह वर्णन करने के लिए शब्द नहीं हैं कि क्या हुआ।

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

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

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

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

क्या स्प्रिंग सिक्योरिटी के साथ कोई ज्ञात बग है जो इसी तरह के मुद्दों का कारण बनती है? क्या एप्लिकेशनकॉन्टेक्स्ट से गलत सत्र स्थिति की गलती से सेवा करने के बारे में टोमकैट के साथ ज्ञात समस्याएं हैं? क्या किसी और ने ऐसी ही समस्या का अनुभव किया है या इसमें कुछ अनूठी अंतर्दृष्टि है?

संपादित करें: फौरन इस पोस्ट करने के बाद मैं इस पाया, केवल कुछ ही दिन पहले पोस्ट की गई:

Session mix up - apache httpd with mod_jk, tomcat, spring security - serving data of other user

यह लगभग ठीक उसी सेटअप है के रूप में मैं अपाचे httpd + mod_jk के सामने प्लगइन है बिलाव तो निश्चित रूप से मैं पागल नहीं हूँ :)

अद्यतन:

मैं मीटर में समस्या को ठीक करने में सक्षम था y विकास वातावरण बिना mod_jk या अपाचे के सामने, इसलिए मैं अपराधी के रूप में इस पर भरोसा कर सकता हूं।

Answer 1

मैं इसे लगा बाहर :)

यह एक डेवलपर त्रुटि की तरह था, लेकिन यह भी वसंत के एक हास्यास्पद डिफ़ॉल्ट व्यवहार है। मेरे पास जेएसएफ प्रबंधित बीन था जिसे सत्रबीन कहा जाता था जिसे मैंने @SessionScope के रूप में घोषित किया था। जब आप जेएसएफ और स्प्रिंग को एकीकृत करते हैं, तो जेएसएफ निर्भरता इंजेक्शन स्प्रिंग निर्भरता इंजेक्शन के साथ संघर्ष करता है, इसलिए वसंत जेएसएफ मॉड्यूल को फिर से लिखता है जो इसके बजाय बस स्प्रिंग डी को लपेटने के लिए संभालता है। इसलिए जब मैं जेएसएफ प्रबंधित बीन को सत्र स्कोप्ड के रूप में घोषित करता हूं, तो मुझे इसे @Controller एनोटेशन भी देना होगा ताकि इसे स्प्रिंग बीन के रूप में भी पहचाना जा सके।

बताता है कि वसंत हालांकि जेएसएफ @RequestScoped और @SessionScoped एनोटेशन को समझ नहीं पाता है।वसंत में अपनी खुद की एनोटेशन है जिसे @Scope(value = "request|session|singleton?|etc...") कहा जाता है।

क्योंकि वसंत ने सेट किए गए जेएसएफ स्कोप को पहचाना नहीं है, इसलिए उसने सिंगल निर्मित बीन को बीन्स के लिए डिफ़ॉल्ट रूप से एक सिंगलटन के रूप में माना।

इसलिए हर बार किसी ने लॉग ऑन किया, यह उस संपत्ति को ओवरराइट कर रहा था जिसे मैंने लॉग इन उपयोगकर्ता को कैश करने के लिए उपयोग किया था जिसे मैंने प्रमाणीकरण प्रिंसिपल से लाया था। फिर हर कोई जो कुछ भी करता था, एक अलग उपयोगकर्ता के रूप में लॉग ऑन किया गया था।

के रास्ते से वसंत का अच्छा आपको चेतावनी देता है कि आपने अपने लानत बीन को गलत तरीके से कॉन्फ़िगर किया है।

हर किसी की सहायता के लिए धन्यवाद, मुझे उम्मीद है कि यह भविष्य के आगंतुकों को लाभान्वित करेगा!