2011-12-21 13 views
9

मैं एमवीसी 3 का उपयोग कर रहा हूं और सब कुछ जो मैं देख सकता हूं उससे ठीक से सेटअप किया गया है।एक आवश्यक एंटी-जालसाजी टोकन की आपूर्ति नहीं की गई थी या

एक उपयोगकर्ता प्रमाणीकरण एंटीफॉर्गेरी टोकन के साथ एक फॉर्म सबमिट करता है और सब कुछ ठीक काम करता है।

यह तब तक है जब तक उपयोगकर्ता ने फॉर्म को खोलने के लिए छोड़ दिया है और उस समय के भीतर उपयोगकर्ता लॉगिन समाप्त हो गया है।

जब उपयोगकर्ता फॉर्म सबमिट करता है क्योंकि उन्हें अब प्रमाणित नहीं किया जाता है तो उन्हें साइन इन पेज पर वापस ले जाना चाहिए। (यह कुछ बार होता है)

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

अपवाद सही है लेकिन इसे कभी भी फेंक दिया नहीं जाना चाहिए क्योंकि पृष्ठ को लॉग इन स्क्रीन पर वापस कूदना चाहिए क्योंकि असली समस्या यह है कि उपयोगकर्ता एक खुले रूप से दूर चला गया और उसका लॉगिन समय समाप्त हो गया।

यह समस्या दोहराना मुश्किल है क्योंकि यह हमेशा ऐसा नहीं करता है।

मुझे लगता है कि बहुत से लोगों को यह समस्या हो रही है लेकिन कोई समाधान नहीं आ रहा है।

क्या यह एमवीसी के भीतर ही एक समस्या है?

मशीन कुंजी सेटिंग और सामान सभी सही हैं इसलिए समस्या नहीं है।

+0

विरोधी जालसाजी सामान वास्तव में 'System.Web.WebPages' में होता है, एमवीसी नहीं। तो आप एमवीसी की बजाय उस स्रोत को देखना चाहते हैं। –

+0

मुझे यकीन नहीं है कि एंटीफोर्गेरी टोकन के पास उपयोगकर्ता के साथ कुछ भी करना है, क्योंकि इसका उपयोग प्राधिकरण के बावजूद किया जा सकता है। यह समय से संबंधित हो सकता है। – stevethethread

उत्तर

2

मैं एक बेहतर जवाब यहाँ जोड़ रहा है क्योंकि इस तरह के एक दर्द है और खराब सभी वेब मैं मैं अपने वर्तमान काम कर समाधान जोड़ना होगा सोचा से अधिक जवाब दे दिया।

मौलिक रूप से (विभिन्न विकल्पों को अनदेखा कर रहा है) एंटीफॉर्गेरी टोकन एक सत्र कुकी जोड़कर काम करता है जिसे तब लिखा जाता है जब फ़ॉर्म को [ValidateAntiForgeryToken] विशेषता के साथ नियंत्रक को सजाने के द्वारा पोस्ट किया जाता है।

सामान्य नियम के रूप में कुछ भी ठीक करने से पहले हम हमेशा निम्नलिखित करते हैं।

  1. web.config में निम्नानुसार मशीन बनाएं।

    <machineKey validationKey="YOUR_KEY" decryptionKey="YOUR_KEY" validation="SHA1" decryption="AES" />

    ** ध्यान दें SHA1 यह नहीं वास्तव में बहुत सुरक्षित अब thats एक और चर्चा **

    गूगल <machineKey> Generator और कॉन्फ़िगर है, लेकिन।

    http://msdn.microsoft.com/en-us/library/w8h3skw9%28v=vs.100%29.aspx

  2. बदलें डिफ़ॉल्ट कुकी कि अन्य अनुप्रयोग द्वारा नहीं इस्तेमाल किया जाएगा एक के लिए '__RequestVerificationToken' नाम। (मैं हमेशा एक GUID का उपयोग करता हूं)।

    AntiForgeryConfig.CookieName = "YOUR_NAME";

  3. साथ ऐसा करें एक नया कस्टम विशेषता बनाएँ।

इस त्रुटि को किसी कारण से प्रकट होने का कारण यह नहीं है कि कुकी केवल सत्र के जीवन के लिए मान्य है। विभिन्न कारणों से, लेकिन अधिकतर तथ्य यह है कि लोग पृष्ठ छोड़ते हैं, सत्र समय समाप्त होने में बहुत लंबे समय तक खुलते हैं। क्योंकि सत्र का समय समाप्त हो गया है, कुकी अब मान्य नहीं है।

एक और मुद्दा यह है कि अगर आपके पास नियंत्रक को पोस्ट पर [अधिकृत] विशेषता है तो चीजों का प्रवाह HttpAntiForgeryException को आग लगने से पहले यह जांचने से पहले कि कौन प्रमाणित है। (सत्र की समय सीमा समाप्त होने पर अधिकांश कुकी आधारित प्रमाणीकरण में उपयोगकर्ता अब प्रमाणीकृत नहीं है)

इसे हल करने का तरीका कस्टम [कस्टम ValidateAntiForgeryToken] विशेषता बनाना है।

[AttributeUsage(AttributeTargets.Method | AttributeTargets.Class, AllowMultiple = false, Inherited = true)] 
    public class CustomValidateAntiForgeryToken : FilterAttribute, IAuthorizationFilter { 

    public void OnAuthorization(AuthorizationContext filterContext) { 

     if (filterContext == null) { 
     throw new ArgumentNullException("filterContext"); 
     } 

     try { 
     AntiForgery.Validate(); 
     } 
     catch { 

     // Here do whatever is you wish 
     // you could just re throw the error or what ever. 

     // In this case I have redirected to a Signout 

     filterContext.Result = new RedirectToRouteResult( 
      new RouteValueDictionary( 
      new { 
       action  = "Sign_Out", 
       controller = "SOME_CONTROLLER", 
       area  = "" 
      } 
     ) 
     ); 

     } 

    } 

    } 

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

जाहिर है कि लोगों की काफी अलग ज़रूरत है लेकिन उम्मीद है कि यह इस सामान्य और परेशान समस्या को नियंत्रित करने के लिए पर्याप्त सलाह देता है।

यदि कोई ऐसा कुछ भी देखता है जो मदद करेगा या जोड़ा जा सकता है तो कृपया करें।

1

अपने एक्शन पर [ValidateAntiForgeryToken] विशेषता ऊपर [Authorize] विशेषता डाल दिया। वे ऊपर से क्रम में निष्पादित करते हैं। इसलिए, इसे अधिकृत करना चाहिए और देखें कि अब आप प्रमाणित नहीं हैं।

+0

आपके द्वारा लिखे गए क्रम में गुणों को पुनर्प्राप्त करने की गारंटी नहीं है, है ना? –

+0

Ryand.Johnson जो पहले से ही मामला है हालांकि वास्तव में समस्या का कारण नहीं होना चाहिए –

5

इसका कारण यह है कि कुछ बड़े संगठनों में लोग अपनी मशीनों को फिर से शुरू किए बिना चालू करते हैं और ब्राउज़र बहुत लंबे समय तक उन्हें बंद किए बिना खुलते हैं। कभी-कभी अंत में सप्ताह भी।

यदि मशीन कुंजी को बाद की तारीख में बदल दिया गया है या बदल दिया गया है, तो मशीनों को बंद नहीं किया गया है या ब्राउज़र बंद हो गया है, वे इस त्रुटि के कारण हैं। एक बार प्रत्येक मशीन को रीबूट कर दिया गया है या ब्राउज़र बंद होने पर त्रुटि बंद हो जाएगी।

नोट: इस त्रुटि को रोकने के लिए मशीन कुंजी बनाने के लिए भी महत्वपूर्ण है।

गूगल: मशीन की जेनरेटर

+4

मुझे नहीं पता कि यह क्यों मतदान किया गया है। यह वही है जो हमारे लिए समस्या पैदा कर रहा था और एक बार मशीन कुंजी जोड़ने के बाद और सभी मशीनों को रिबूट किया गया था अब समस्या नहीं हुई है। –

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

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