TempData: क्या यह सुरक्षित है?

Question

RedirectToAction का उपयोग करते समय मेरे मॉडल को संरक्षित करने के लिए मैं TempData का उपयोग कर रहा हूं। यह ठीक काम करता है, लेकिन मुझे एक नाराज लग रहा है कि यह करने के लिए सही काम नहीं हो सकता है। मैं वास्तव में सत्र डेटा का उपयोग करने से बचने की कोशिश करता हूं, और मैंने पढ़ा है कि TempData सत्र का उपयोग करता है। क्या यह उपयोग करने के लिए सुरक्षित है? क्या कोई समस्या है जो लोड संतुलित वातावरण में इसका उपयोग करने में उत्पन्न हो सकती है?

ट्रिविया प्रश्न: "क्या यह सुरक्षित है?" - फिल्म का नाम दें।

Answer 1

हां, टेम्पपडाटा सत्र भंडारण द्वारा समर्थित है, इसलिए यदि आप लोड संतुलित वातावरण में हैं तो इसका उपयोग करते समय अतिरिक्त देखभाल की जानी चाहिए (चिपचिपा सत्र, लगातार सत्र स्थिति, आदि)।

पीआरजी पैटर्न का उपयोग करते समय TempData डी-फैक्टो विकल्प रहा है, और यह इसके लिए डिज़ाइन किया गया था।

यह करने के लिए कि यह सही काम है या नहीं ... यह आपके उपयोग के मामले पर निर्भर करता है!

पीएस मैराथन मैन।

Answer 2

मैंने विचारों और क्रियाओं के बीच मॉडल ऑब्जेक्ट सत्यापन संदेश पास करने के लिए TempData के उपयोग को सीमित कर दिया है। मैंने सुरक्षा परिप्रेक्ष्य से टेम्पपेडाटा के उपयोग को नहीं देखा है, लेकिन एसओ थ्रेड के बाद चर्चा करें: HttpContext.Items with ASP.NET MVC। अंतिम कुछ थ्रेड टिप्पणियां और संबंधित चर्चाएं देखें।

Answer 3

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

इसके अलावा, मैं आपको यह भी मूल्यांकन करने का सुझाव देता हूं कि आप RedirectToAction के बजाय View का उपयोग कर सकते हैं या नहीं। यह:

TempData["model"] = model; 
return RedirectToAction("SomeAction"); 

साथ प्रतिस्थापित किया जा सकता है:

return View("SomeAction", model); 

बेशक

"SomeAction" मानते हुए एक वैध राय यह है कि वर्तमान नियंत्रक से पहुँचा जा सकता है है (यह या तो एक ही ctrl या एक में एक दृश्य में परिभाषित किया गया साझा में) और यह केवल एक मध्यवर्ती कार्रवाई नहीं है जो किसी अन्य पर रीडायरेक्ट करता है।

Answer 4

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

TempData अल्पकालिक है, और यदि आप वहां बहुत सारी वस्तुओं को नहीं डालते हैं और पूरे वास्तुकला के बारे में दो बार सोचते हैं, तो मुझे लगता है कि यह सुरक्षित है। ऐसी कई साइटें हैं जो इसे व्यापक रूप से उपयोग करती हैं और इसमें कोई समस्या नहीं है (मैंने 50-70k विज़िटर/दिन का उपयोग करने के लिए साझा और समर्पित होस्टेड साइटों पर काम किया है, जो सत्र का उपयोग करते हैं, अक्सर वेब और डीबी के साथ उसी सर्वर पर)।

Answer 5

सेशन स्टेट संकुल वातावरण में काम कर सकते हैं, उपलब्ध कराने के दो में से एक होता है कि

1. आपका लोड संतुलन "sticky" sessions का समर्थन करता है (अर्थातकिसी सत्र के दौरान सभी अनुरोधों को एक ही मशीन)
2. आप सत्र प्रदाता कॉन्फ़िगर प्रक्रिया सत्र प्रदाता के बाहर का उपयोग करने के लिए रूट किया जाता है, तो आप उपयोग कर सकते हैं या तो ASP.NET State Service या SQL Session State Provider

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