उद्देश्य

Question

मैं web.config

<pages enableEventValidation="false"> 

में निम्नलिखित यह एक समस्या हम अजाक्स के साथ होने को सही किया गया है का उपयोग किया है।

हमारे पास एक वेब पेज है कि यदि आप सीधे मानक HTML हाइपरलिंक का उपयोग करने के लिए ब्राउज़ करते हैं तो ठीक काम करता है।

यदि आप ग्रिडव्यू के अंदर लिंक के माध्यम से किसी अन्य पृष्ठ से पृष्ठ पर ब्राउज़ करते हैं और rowCommand ईवेंट में respond.redirecting क्वेरीस्ट्रिंग में किसी आईडी को पास करने वाले पृष्ठ पर भेजते हैं। पृष्ठ

"अमान्य पोस्टबैक या कॉलबैक तर्क। कॉन्फ़िगरेशन या <% @ पृष्ठ EnableEventValidation =" true "%> पृष्ठ में सुरक्षा सत्यापन का उपयोग कर सक्षम है। सुरक्षा उद्देश्यों के लिए, यह सुविधा सत्यापित करता है कि पोस्टबैक या कॉलबैक घटनाओं के तर्क उन सर्वर नियंत्रण से उत्पन्न होते हैं जो मूल रूप से उन्हें प्रदान करते हैं। यदि डेटा मान्य और अपेक्षित है, तो क्लाइंटस्क्रिप्ट मैनेजर का उपयोग करें। रजिस्ट्रारफॉरवेन्ट वैलिडेशन विधि सत्यापन के लिए पोस्टबैक या कॉलबैक डेटा पंजीकृत करने के लिए। "

I पृष्ठ सत्यापन को झूठी के रूप में छोड़कर मुझे खुशी है क्योंकि ऐसा कोई अन्य प्रभाव नहीं पड़ा है।

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

Answer 1

documentation पढ़ें।

EDIT: सुरक्षा कारणों से, यह संभव है कि आप जहां भी कर सकें, इसे सही पर सेट करना सबसे अच्छा हो।

इसलिए मैं अनुशंसा करता हूं कि आप इसे केवल व्यक्तिगत AJAX पृष्ठों पर झूठी पर सेट करें जहां यह समस्याएं पैदा करता है, जबकि इसे web.config में सही छोड़ दिया जाता है।

Answer 2

here

अमान्य PostBack या कॉलबैक तर्क त्रुटि से मूल रूप से घटना मान्यता सुविधा की वजह से बढ़ा है। इवेंट वैलिडेशन फीचर एएसपी.नेट 2.0 में एक नई सुविधा है, और यह सत्यापित करने के लिए एक अतिरिक्त स्तर की जांच प्रदान करता है कि क्लाइंट पर नियंत्रण से पोस्टबैक वास्तव में उस नियंत्रण से है और किसी क्रॉस-साइट स्क्रिप्ट इंजेक्शन की तरह किसी दुर्भावनापूर्ण से नहीं चीजों को आजमाने और कुशल बनाने के लिए। यह प्रोग्रामिंग मॉडल में गहराई से स्तरों में सुरक्षा को जोड़ने की हमारी समग्र रणनीति का हिस्सा है - ताकि डेवलपर्स डिफ़ॉल्ट रूप से सुरक्षित हो सकें, भले ही वे स्वयं की सुरक्षा जांच जोड़ना भूल जाएं।

अब, अमान्य PostBack या कॉलबैक तर्क त्रुटि उत्पन्न हो सकती है जब आप क्लिक करें घटना सक्रिय हो रहे हैं और वस्तु rebinding है या उसके गुण Page_Load घटना में बदल रहे हैं या कोई क्रॉस साइट स्क्रिप्टिंग के साथ अपने सिस्टम को हैक करने की कोशिश कर रहा है। हर बार .Net Framework एक पृष्ठ प्रस्तुत करता है तो यह सभी नियंत्रणों के लिए एक अद्वितीय ग्रिड को जोड़ता है। जब एक ग्रिडव्यू या दोहराना बाध्यकारी होता है, तो प्रत्येक डेटाबेस ढांचे पर contorl के लिए एक नया guid संबद्ध होगा। तो हर बार जब आप फायरिंग इवेंट कर रहे हैं तो सुनिश्चित करें कि पेज_लोड ईवेंट नियंत्रण नहीं बदलता है, क्योंकि अगर नियंत्रण बदल जाता है तो इसमें एक अलग ग्रिड होगा जिसने पोस्टबैक के लिए घटना को निष्पक्ष रूप से निकाल दिया है। यहां इस त्रुटि के साथ कुछ परिदृश्य हैं।

1) ग्रिड व्यू समस्या में अमान्य पोस्टबैक या कॉलबैक तर्क हो सकता है: आप पेज_लोड ईवेंट में ऑब्जेक्ट डेटा स्रोत या मैन्युअल बाइंडिंग के साथ फ़ंक्शन कॉल के साथ डेटा बाध्य कर रहे हैं। यह आपके ग्रिड व्यू को किसी भी नियंत्रण की हर घटना की आग पर डेटा बांध देगा।जब आप OnRowCommand के साथ किसी भी GridView कमांड को फायर कर रहे हैं, रोवॉमैंड आग से पहले आपके ग्रिड व्यू को रिबाइंड कर दिया जाएगा और इसके भीतर सभी नियंत्रण नए आईडी को सौंपा जाएगा। तो रोकॉमैंड उस आइटम को नहीं मिला जिसने घटना को निकाल दिया है। GridView में अमान्य पोस्टबैक या कॉलबैक तर्क के लिए समाधान: आप इस के अंतर्गत अपना डेटा बाध्य कर सकते हैं अगर हालत

if (!IsPostBack) 

    { 

      //Your code for Bind data 

    } 

अगर यह काम नहीं जाँच करें कि क्या किसी अन्य नियंत्रण त्रुटि न जताए इस कोड को निश्चित रूप से आप समाधान दे देंगे।

Answer 3

यहाँ जोड़ने के लायक एक चीज नहीं है:

: अगर आप पूरे पृष्ठ की तुलना में एक विशिष्ट नियंत्रण के लिए घटना सत्यापन अक्षम करने के लिए, चाहते हैं, तो एक समाधान here और here दस्तावेज (और अब relevant Connect suggestion में संदर्भित) है

बस प्रासंगिक वेबकंट्रोल क्लास को उपclass, और subclass पर SupportsEventValidation विशेषता सेट न करें। सबक्लास को ईवेंट सत्यापन से छूट दी जाएगी।