2010-05-06 11 views
12

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

मैं (लेकिन मालूम होता है बेतरतीब ढंग से) अपने खुद के परीक्षण के दौरान इस बग मिल गया है और मुझे लगता है कि वास्तविक लॉग-इन उपयोगकर्ताओं के लिए यह रूप में अच्छी तरह हो रही है मेरी लॉगिंग से पता है।

किसी को भी पता है क्या antiforgerytoken प्रणाली (एक वास्तविक हमले के अलावा अन्य) को तोड़ने के लिए कारण होगा, और कैसे मैं अपने रूपों में एक सुरक्षा छेद खोले बिना इसे ठीक कर सकता है?

धन्यवाद!

+0

MVC2 से परिचित नहीं है, लेकिन अगर यह एक है दुर्लभ घटना, मुझे संदेह होगा कि उपयोगकर्ता उस पृष्ठ को लोड करने के दौरान टोकन समाप्त हो रहा है, और फ़ॉर्म सबमिट करता है। – mpen

+0

चिह्न - मुझे लगता है कि वास्तव में यह हो सकता है। अगर आपको जवाब मिल जाता है तो आपको इसे एक उत्तर के रूप में पोस्ट करना चाहिए। यह कोई समाधान नहीं है - लेकिन यह समस्या हो सकती है। मैं एक समाप्ति टोकन कैसे संभाल सकता हूं? समय समाप्त होने में कितना समय लगता है? –

+0

MVC3 और फ़ायरफ़ॉक्स का उपयोग करके परीक्षण किए जाने पर __RequestVerificationToken_Lw__ कुकी सत्र के अंत में समाप्त हो जाती है। मैं एक त्रुटि को लात मारने के बजाए कुकी को ताज़ा करने के लिए पेज रीलोड को मजबूर करने का एक तरीका ढूंढना चाहता हूं। –

उत्तर

1
+0

नहीं, यह सब ठीक से स्थापित है। त्रुटि सप्ताह में या तो कभी-कभी और कभी-कभी भारी परीक्षण के दौरान होती है। –

+0

धन्यवाद जेसन, मैं इसे एक पढ़ा दूंगा। –

+0

एकमात्र ऐसा लगता है कि मैंने वहां देखा है जो मैंने कार्यान्वित किया है उससे अलग है, वे यह दिखाते हैं: <% का उपयोग (HTML.Form ("UserProfile", "SubmitUpdate")) {%> <% = HTML .AntiForgeryToken()%> <- प्रपत्र के बाकी यहाँ जाता है -> <% } %> जब मैं आमतौर पर कार्यान्वित इस: <% का उपयोग कर (Html.Form ("UserProfile", "SubmitUpdate")) {% > <% = Html.AntiForgeryToken()%> <% } %> के बाद से इस एक फार्म पोस्ट है, मुझे लगता है कि नहीं था इससे कोई फर्क होता है, और मैं अभी भी डॉन ' टी। लेकिन इस बिंदु पर मैं इसे काम करने के लिए कुछ भी बदल दूंगा। –

0

सुनिश्चित करें कि आपके ~/Web.config एक <machineKey> खंड हो और आपको लगता है कि अनुभाग में से कुंजी स्थापित कर रहे हैं कि यहाँ पर अनुभाग पढ़ें। एंटी-एक्सएसआरएफ सिस्टम को उपस्थित होने की आवश्यकता है।

+0

मैंने इस समस्या को ठीक करने के अपने अंतिम प्रयास के दौरान पहले से ही यह किया है। इससे मदद नहीं मिली, लेकिन सैद्धांतिक रूप से यह एक आवश्यक कदम था। धन्यवाद –

+0

यदि आपके पास अपने मशीन के इवेंट लॉग तक पहुंच है, तो क्या आप इसे एंटी-एक्सएसआरएफ अमान्य अपवाद के रूप में एक ही समय में होने वाली किसी भी प्रविष्टि के लिए देख सकते हैं? उदाहरण के लिए, क्या ऐपडोमेन पुनरारंभ करने के तुरंत बाद ऐसा होता है? – Levi

+1

मैं इस लेवी, एक और दिलचस्प विचार में देख लूंगा। सुनिश्चित नहीं है कि सत्र की समाप्ति या ऐपडोमेन इस बिंदु पर पुनरारंभ होता है - दोनों सुझाव व्यावहारिक लगते हैं। एक बार फिर धन्यवाद! –

1

सुनिश्चित नहीं हैं कि अगर इस में मदद मिलेगी, लेकिन मैंने पाया कि जब इंटरनेट एक्सप्लोरर का उपयोग मैं Firefox पर यह त्रुटि प्राप्त होगा जब भी एक अंडरस्कोर '_' उप डोमेन के अंदर था ... लेकिन नहीं।

फिर भी एक समाधान या तर्क की तलाश में। सुनिश्चित करने के लिए

+0

धन्यवाद IoSamurai! मैंने कभी अपराधी होने के लिए अंडरस्कोर नहीं सोचा होगा। – Warren

4

एक बात have the same machine key token for all requests है। यदि आपके पास यह नहीं है और आपका एप्लिकेशन पूल रीसायकल करता है, तो पुराने कुकीज़ वाले बाद के POSTs इस त्रुटि का कारण बनते हैं।

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

+0

फ़ायरफ़ॉक्स में समस्या हो रही थी। काम नहीं कर सका - क्यों - सभी कारणों से सभी कुकीज़ अक्षम कर दी गईं। मेरा सिद्धांत यह है कि मैंने उन्हें फायरबग में अक्षम कर दिया था (जिसे मैंने तब अनइंस्टॉल किया था), और यह सेटिंग बनी रही। –

8

यहाँ a similar question करने के लिए अपने जवाब के एक हिस्से को बताया गया है:

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

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

+1

यह वही परिदृश्य है जो मेरे पास है, लेकिन मैं पहले से ही अपने web.config में मशीन कुंजी का उपयोग कर रहा हूं। मेरे पास दूसरा विचार यह है कि उपयोगकर्ता के पास "मुझे याद रखें" सुविधा के लिए कुकी है जो गैर-समाप्त हो रही है। क्या यह संभव है कि यह गैर-समाप्त करने वाली कुकी विरोधी जालसाजी टोकन/अनुरोधकर्ता कुकी से जुड़ा हुआ है, जब वह समाप्त हो रहा है, इस प्रकार "मुझे याद रखें" कुकी से अलग है? – ganders

0

जैसा कि उत्तर ने टिप्पणी पर टिप्पणी में कहा था, मैं इसे हर समय देखता हूं जब उपयोगकर्ता 20 मिनट से अधिक समय तक (पेज का डिफ़ॉल्ट सत्र समय) और टोकन की समयसीमा समाप्त करते हैं।

आप को गति प्रदान या इस त्रुटि के लिए मजबूर अपने ब्राउज़र के डेवलपर उपकरण खोलने और __RequestVerificationToken छिपी हुई फ़ील्ड को हटा कर (यदि आप इसे पकड़ने का परीक्षण करने की कोशिश कर रहे हैं) कर सकते हैं:

<input name="__RequestVerificationToken" type="hidden" value="AqJL/+e9tGCSCXdurrXDRefVL/TAdOAG9Hjrx0oMPg6sVZY3xv099OSYlH1qI8uZyu4x2xFj9eiNVSH2BGsSfJCQAqzxfQtIKoHXNkkW2FJTkxzsNRkwZo1SJUzYGvcEJ/OJ0AouiUWh98qyIzgN2ZkKP7k="> 
संबंधित मुद्दे

 संबंधित मुद्दे