POST + HTTP रीडायरेक्ट

Question

के बाद उपयोगकर्ता को संदेश कैसे प्रदर्शित करें I एकाधिक फॉर्म सबमिशन से बचने के लिए PRG pattern का उपयोग कर रहा हूं। हालांकि, यह एक गंभीर कमी है - आप उपयोगकर्ता को पुष्टिकरण संदेश नहीं दे सकते हैं (जाहिर है, उपयोगकर्ता पृष्ठ नहीं देखेगा, उसे दूसरे पर रीडायरेक्ट किया जाएगा)।

इस समस्या के समाधान क्या हैं? मैं उनमें से दो को जानता हूं, लेकिन उनमें से कोई भी सही नहीं लगता है।

• कस्टम रीडायरेक्ट यूआरएल का उपयोग करें, जैसे: http://example.com/?msg=data-saved। यह स्टेटलेस है, इसलिए मुझे लगता है कि यह काफी विश्वसनीय है। लेकिन जब उपयोगकर्ता लिंक कॉपी करता है, बुकमार्क करता है, इत्यादि।
• एक सत्र चर/कुकी स्टोर करें, और इसे प्रत्येक पृष्ठ लोड पर जांचें। यदि यह सेट है, तो इसे साफ़ करें और संदेश प्रदर्शित करें। यह ठीक लगता है, लेकिन मुझे इस बारे में निश्चित नहीं है - यह कुकीज़ पर दृढ़ता से निर्भर करता है, यह थोड़ा और जटिल है।

या शायद ऐसे अन्य तरीके हैं जिनके बारे में मुझे नहीं पता? सत्र और यूआरएल पैरामीटर के कुछ संयोजन? पता नहीं।

आपकी राय में सबसे अच्छा तरीका क्या है? किसके पास कम से कम कमियां हैं? पक्ष और विपक्ष क्या होते हैं?

Answer 1

बहुत सारी वेबसाइट जो उपयोगकर्ताओं को लॉग इन करने की अनुमति देती है, कुकी पर भरोसा करते हैं। यह एक आदर्श समाधान नहीं है, लेकिन यह हमें सबसे अच्छा मिला है।

सत्र सत्र हैंडलिंग उन चीजों में से एक है जो एक वेब विकास ढांचा आम तौर पर आपकी देखभाल करता है।

Answer 2

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

Answer 3

यह इस बात पर निर्भर करता है कि आप किस प्लेटफॉर्म पर चल रहे हैं।

रूबी ऑन रेल्स कॉल इस फ़्लैश [: नोटिस] = "आपकी कार्रवाई प्रदर्शन किया गया था", ASP.NET MVC कॉल इस TempData [ "नोटिस"] = "आपकी कार्रवाई प्रदर्शन किया गया था" ...

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

Answer 4

ऐसे कई अन्य स्टैक ओवरफ़्लो प्रश्न हैं जो इस पर स्पर्श करते हैं, हालांकि मुझे नहीं लगता कि समस्या को स्पष्ट रूप से सारांशित किया गया है। यहाँ कुछ कर रहे हैं:

• How do I implement the Post/Redirect/Get pattern in asp.net WebForms?
• Response.Redirect with POST instead of Get?
• दोनों HTTP GET with request body और Can an HTTP GET legally contain content? मुद्दे पर पहुंचते हैं, और विचार विमर्श पढ़ने लायक हैं।
• How do I maintain ModelState errors when using RedirectToAction?

सुविधाजनक समाधान के अधिकांश सत्र-आधारित हैं या (जैसे क्वेरी स्ट्रिंग में संदेश embedding के रूप में) और अधिक गंभीर कमियां हैं।

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

Answer 5

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

और ईमानदारी से, कुछ ऐसी साइटें जो सामान्य रूप से इस तरह की चीज़ के बारे में बहुत अच्छी हैं, यूआरएल में "actiondone = true" चिपक जाती हैं। (मैंने देखा है फेसबुक कुछ स्थानों में यह होता है।)

Answer 6

इस चर्चा करने के लिए बहुत देर हो चुकी आ रहा है ..

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

का संकेत इस अनुरोध के लिए कोई जवाब हो सकता है कि एक यूआरएल के लिए पोस्ट अनुरोध ग्राहक रीडायरेक्ट किया जाता है (303) के बाद:

Client: GET http://example.com/foo.cgi 
Server: 200 Ok 

Client: POST http://example.com/bar.cgi 
Server: 303 http://example.com/foo.cgi?msg=true 

तो msg तर्क true है संदेश में देखा जाएगा सत्र और (यदि पाया गया) क्लाइंट के जवाब में शामिल है।
यदि msg तर्क ! true (या मौजूद नहीं है), तो लुकअप चरण छोड़ दिया गया है।

इस समाधान के साथ, आप यूआरएल में वास्तविक संदेश दिखाए जाने से रोकते हैं, यूआरएल केवल इंगित करता है कि एक संदेश हो सकता है। साथ ही, संदेश केवल तभी दिखाया जाता है जब आवश्यक हो (= सत्र में मिलने पर)।

एक अन्य लाभ यह है कि यह समाधान HTTP प्रतिक्रियाओं के साथ उचित नकद-नियंत्रणों को शामिल करने की अनुमति देता है।