AJAX के अनुरोध की सही हैंडलिंग ASP.NET MVC अनुप्रयोगों के लिए प्रमाणीकरण समस्याओं का अनुरोध करती है

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

समस्या

मान लीजिए कि jQuery का उपयोग करने वाला हमारा वेब एप्लिकेशन सर्वर तक पहुंचता है और वहां से JSON के रूप में डेटा प्राप्त करता है।

सर्वर:

  [HttpPost]
 सार्वजनिक ActionResult GetData ()
 {

	 वापसी Json (नया)
	 {
		 आइटम = नया []
		 {
			 "ली चेन",
			 "अब्दुल्ला ख़मीर",
			 "मार्क श्रीनबर्ग",
			 "केटी सुलिवन",
			 "एरिको गैंटोमारो",
		 }
	 });
 } 

ग्राहक:

  var $ सूची = $ ("# सूची");
 var $ स्थिति = $ ("# स्थिति");
 $ list.empty ();
 $ status.text ("लोड हो रहा है ...");

 $ .post ("/ होम / गेटडाटा")
	 .always (फ़ंक्शन () {
		 $ स्थिति। खाली ();
	 })
	 .success (फ़ंक्शन (डेटा) {
		 के लिए (var i = 0; मैं <data.Items.length; i ++) {
			 $ list.append ($ ("<li />")। पाठ (data.Items [i]));
		 }
	 }); 

तर्क अत्यंत सरल और सीधा है। अब हम अपने आवेदन में प्रमाणीकरण तंत्र जोड़ेंगे। इसके साथ, फिर से, सब कुछ काफी सरल है - हम ASP.NET MVC में अच्छे पुराने फॉर्म ऑथेंटिकेशन तंत्र और अधिकृत विशेषता का उपयोग करते हैं। हमारे नियंत्रक का कोड निम्नानुसार बदल जाएगा:

  [HttpPost]
 [अधिकृत]
 सार्वजनिक ActionResult GetData ()
 {
	 वापसी Json (नया)
	 {
		 आइटम = नया []
		 {
			 "ली चेन",
			 "अब्दुल्ला ख़मीर",
			 "मार्क श्रीनबर्ग",
			 "केटी सुलिवन",
			 "एरिको गैंटोमारो",
		 }
	 });
 } 

फिर से - इस कोड के साथ कोई समस्या नहीं है। प्रमाणीकरण के बाद, उपयोगकर्ता पृष्ठ को देखता है और पहले की तरह डेटा प्राप्त कर सकता है। हालाँकि, समस्या यह है कि यदि प्रमाणीकरण समय समाप्त हो जाता है (उपयोगकर्ता निष्क्रियता के कारण) या उपयोगकर्ता लॉग आउट करता है (उदाहरण के लिए, किसी अन्य ब्राउज़र टैब में), तो सर्वर वापस आ जाएगा ... HTTP 302 नियंत्रक को कॉल के जवाब में मिला ।



जाहिर है, हमारे मामले में क्लाइंट कोड ने घटनाओं के इस तरह के मोड़ की उम्मीद नहीं की थी और आगे आवेदन सही ढंग से काम नहीं करेगा।

कारणों

समस्या को हल करने से पहले, आइए कारणों पर गौर करें - HTTP 302 कहां से आया? ऐसा लगता है - 302 कहाँ से आता है? यह मानना तर्कसंगत होगा कि HTTP 401 होना चाहिए। तथ्य यह है कि जब हम FormsAuthentication का उपयोग करते हैं, FormsAuthenticationModule (जो वैश्विक कॉन्फ़िगरेशन फ़ाइल में HTTP मॉड्यूल की सूची में जोड़ा जाता है) पर्दे के पीछे कार्य करता है। इस मॉड्यूल के हुड के नीचे देखते हुए, आप आसानी से समझ सकते हैं कि यदि HTTP के लिए वर्तमान कोड 401 है, तो यह रीडायरेक्ट करता है, अर्थात। इसे 302 से बदल देता है:



यह अनुमान लगाना आसान है कि यह उपयोगकर्ता को पासवर्ड प्रविष्टि पृष्ठ पर पुनर्निर्देशित करने के लिए किया गया था यदि अनुरोध को सफलतापूर्वक संसाधित नहीं किया गया है और पासवर्ड आवश्यक है (रिटर्न कोड - 401)। इस स्थिति में, उपयोगकर्ता को एक अनुकूल पासवर्ड प्रविष्टि फ़ॉर्म दिखाई देगा, और त्रुटि कोड वाला IIS पृष्ठ नहीं। यह समझ में आता है, है ना?

हमारे ASP.NET MVC एप्लिकेशन के दृष्टिकोण से, श्रृंखला इस प्रकार है:

1. अनुरोध आवेदन के लिए आता है, जहां यह प्राधिकरण ऑथराइटर फिल्टर पर ठोकर खाता है।
2. चूंकि उपयोगकर्ता प्रमाणित नहीं है, यह फ़िल्टर HTTP 401 को लौटाएगा, जो कि तार्किक है (आप इस फ़िल्टर के कार्यान्वयन को एक परावर्तक के साथ देखकर आसानी से सत्यापित कर सकते हैं)।
3. ठीक है, तो हमारे FormsAuthenticationModule काम करता है, जो 401 को पुनर्निर्देशित करता है।

नतीजतन, जब पासवर्ड-रक्षित पृष्ठ तक पहुँचते हैं, तो हम एक पासवर्ड प्रविष्टि फ़ॉर्म ( जो अच्छा है ) देखते हैं, लेकिन AJAX के माध्यम से समान संसाधनों तक पहुँचते समय, यह उत्तर सूचनात्मक नहीं है ( जो खराब है )।

निर्णय

तो समस्या को हल करने के लिए आपको क्या चाहिए -

1. सर्वर ने AJAX अनुरोधों के लिए 401/403 और सामान्य अनुरोधों के लिए 302 दिए।
2. क्लाइंट 401/403 पर प्रक्रिया।

ईमानदारी से, FormsAuthenticationModule को 401 के साथ अनुरोधों को बदलने के लिए मजबूर नहीं किया जा सकता है। इसके लिए, HttpResponse के पास एक विशेष गुण है - SuppressFormsAuthenticationRedirect :



एकमात्र सवाल यह है कि इस संपत्ति को बदलने के लिए कौन से मामलों में और कोई कम महत्वपूर्ण नहीं है, जो वास्तव में ऐसा करेगा?

इस सवाल का जवाब देने से पहले, आइए ध्यान दें कि AJAX अनुरोध के जवाब में त्रुटि के साथ HTTP प्रतिक्रिया प्राप्त करने पर ग्राहक को कैसे प्रतिक्रिया देनी चाहिए। दो परिदृश्य हो सकते हैं:

1. उपयोगकर्ता सिस्टम ( 401 ) में बिल्कुल भी प्रमाणित नहीं है और इसे पासवर्ड लॉगिन के साथ पृष्ठ पर भेजा जाना चाहिए।
2. उपयोगकर्ता प्रमाणित है, लेकिन यह कार्रवाई अभी भी उसके ( 403 ) के लिए उपलब्ध नहीं है। उदाहरण के लिए, हम कुछ भूमिकाओं के लिए कुछ कार्रवाई की अनुमति दे सकते हैं जो उपयोगकर्ता का सदस्य नहीं है। फिर इसे पासवर्ड प्रविष्टि पृष्ठ पर भेजना शायद बेवकूफी है - इस मामले में उसे केवल यह सूचित करने के लिए पर्याप्त होगा कि उसके पास पर्याप्त अधिकार नहीं है।

इस प्रकार, हमें दो स्थितियों को अलग-अलग ढंग से संभालने की आवश्यकता है। एक रिफ्लेक्टर के साथ ऑथराइज एट्रिब्यूट पर फिर से नज़र डालें।



... यानी। यह हमेशा 401 देता है।

यह अच्छा नहीं है। इसलिए, आपको मानक व्यवहार को थोड़ा सही करना होगा। तो चलो शुरू करते हैं।

सबसे पहले , हम यह निर्धारित करते हैं कि क्या वर्तमान अनुरोध AJAX अनुरोध है और यदि ऐसा है, तो पासवर्ड प्रविष्टि पृष्ठ पर रीडायरेक्ट को अक्षम करें:

  सार्वजनिक वर्ग ApplicationAuthorizeAttribute: AuthorizeAttribute
 {
	 संरक्षित ओवरराइड शून्य हैंडललेनोथोराइज्डRequest (प्राधिकरणकरण फ़िल्टर फ़िल्टरकंटेक्स)
	 {
		 var httpContext = filterContext.HttpContext;
		 var अनुरोध = httpContext.Request;
		 var response = httpContext.Response;

		 यदि (request.IsAjaxRequest ())
			 प्रतिक्रिया।

		 base.HandleUnauthorizedRequest (filterContext);
	 }
 } 

दूसरा - शर्त जोड़ें: यदि उपयोगकर्ता प्रमाणित है, तो 403 दें, यदि नहीं, तो 401:

  सार्वजनिक वर्ग ApplicationAuthorizeAttribute: AuthorizeAttribute
 {
	 संरक्षित ओवरराइड शून्य हैंडललेनोथोराइज्डRequest (प्राधिकरणकरण फ़िल्टर फ़िल्टरकंटेक्स)
	 {
		 var httpContext = filterContext.HttpContext;
		 var अनुरोध = httpContext.Request;
		 var response = httpContext.Response;
		 var उपयोगकर्ता = httpContext.User;

		 यदि (request.IsAjaxRequest ())
		 {
			 अगर (user.Identity.IsAuthenticated == गलत)
				 response.StatusCode = (int) HttpStatusCode.Unauthorized;
			 अन्यथा
				 response.StatusCode = (int) HttpStatusCode.Forbidden;

			 प्रतिक्रिया।
			 response.End ();
		 }

		 base.HandleUnauthorizedRequest (filterContext);
	 }
 } 

नया फिल्टर तैयार है। अब हमें अपने प्राधिकरण में बनाए गए फ़िल्टर का उपयोग करना चाहिए, बजाय मानक प्राधिकारी के। यह सौंदर्यशास्त्र के लिए एक भारी दोष की तरह लग सकता है, लेकिन मुझे कोई दूसरा रास्ता नहीं दिखता। अगर कोई हल है, तो मुझे टिप्पणियों में देखकर खुशी होगी।

खैर, आखिरी बात यह है कि क्लाइंट पर 401/403 प्रोसेसिंग जोड़ें। ऐसा करने से बचने के लिए, प्रत्येक अनुरोध के लिए, आप jQuery में ajaxError हैंडलर का उपयोग कर सकते हैं:

  $ (दस्तावेज) .ajaxError (फ़ंक्शन (ई, xhr))
	 अगर (xhr.status == 401)
		 window.location = "/ खाता / लॉगिन";
	 और अगर (xhr.status == 403)
		 चेतावनी ("आपके पास इस संसाधन का अनुरोध करने के लिए पर्याप्त अनुमति नहीं है");
 }); 

अंत में -

• यदि उपयोगकर्ता को प्रमाणित नहीं किया गया है (उदाहरण के लिए समय समाप्त हो गया है), तो किसी भी AJAX अनुरोध के बाद, उसे पासवर्ड प्रविष्टि पृष्ठ पर भेजा जाएगा।
• यदि उपयोगकर्ता प्रमाणित है, लेकिन कार्रवाई करने का अधिकार नहीं है, तो उसे संबंधित त्रुटि संदेश दिखाई देगा।
• यदि उपयोगकर्ता प्रमाणित है और पर्याप्त अधिकार हैं, तो कार्रवाई की जाएगी।

Minuses की - आपको मानक एक के बजाय नए ApplicationAuthorizeAttribute फ़िल्टर का उपयोग करना होगा। तदनुसार, यदि मानक कोड पहले से ही कोड में उपयोग किया गया था, तो इस कोड को सभी स्थानों में बदलना होगा।

आवेदन का स्रोत कोड github पर है ।