10

मैंने स्प्रिंग एमवीसी के साथ एक आरईएसटी एपीआई बैकएंड बनाया है और स्प्रिंग सिक्योरिटी के साथ मूल एथ के साथ सुरक्षित है।JQuery क्रॉस डोमेन मूल ऑथ कॉल

मैं जावास्क्रिप्ट क्लाइंट से आरईएसटी एपीआई को क्रॉस डोमेन AJAX कॉल करना चाहता हूं। मैं जेएसओएनपी का उपयोग नहीं करना चाहता क्योंकि मैं जीईटी कॉल तक सीमित नहीं होना चाहता हूं। मैं सीओआरएस का उपयोग करता हूं और मैंने दाएं हेडर को सर्वर की तरफ रखा है।

मान लीजिए कि मेरा आरईएसटी एपीआई डोमेन लोकलहोस्ट पर है: 8087 और मेरा ग्राहक लोकलहोस्ट पर: 8086, जो क्रॉस डोमेन कॉल है।

मेरी जावास्क्रिप्ट क्लाइंट में, मैं jQuery के साथ ajax फोन करना:

<script> 
     $.ajax ({ 
      url: "http://localhost:8087/SpringMVC/users/user1", 
      beforeSend: function (xhr) { xhr.setRequestHeader ("Authorization", "Basic xxxxxxxxxxxx"); }, 
      success: function(val) { console.log(val); alert("success" + val); }, 
      error: function(val) { console.log(val); alert("error" + val); } 
     }); 
</script> 

मेरे समस्या यह है कि jQuery HTTP अनुरोध में प्राधिकरण हैडर नहीं भेजा जाता है और मैं पता नहीं क्यों है। मुझे समझ में नहीं आता क्योंकि मैं इसे पहले सेन्ड विधि में करता हूं, इसलिए यह HTTP अनुरोध के अंदर होना चाहिए। परिणाम: मेरे पास 401 त्रुटि है।

जब मैं उसी डोमेन से स्क्रिप्ट का प्रयास करता हूं तो स्थानीयहोस्ट: 8087, जो अब क्रॉस डोमेन नहीं है, मुझे कोई समस्या नहीं है।

यह कैसे संभव है?

मेरी लिपि सिर्फ एक परीक्षा है। मैं क्लाइंट साइड पर अपना उपयोगकर्ता नाम/पासवर्ड डालने का इरादा नहीं रखता हूं। लेकिन मैं परीक्षण करना चाहता हूं कि मूलभूत संरक्षित आरईएसटी एपीआई को AJAX कॉल कैसे करें। मुझे कल्पना है कि मुझे अपना उपयोगकर्ता नाम/पासवर्ड सुरक्षित करने के लिए सर्वर की ओर भेजना है, आरईएसटी एपीआई मुझे एक कुकी वापस भेजती है और मुझे अपने अगले AJAX कॉल के लिए अब उपयोगकर्ता नाम/पासवर्ड पास करने की आवश्यकता नहीं है। क्या मैं सही हू ?

मैंने क्रोम उन्नत आरईएसटी क्लाइंट के साथ अपने आरईएसटी एपीआई का परीक्षण किया है और यह इस तरह काम कर रहा है। पहले अनुरोध के लिए मुझे प्राधिकरण शीर्षलेख पास करने की आवश्यकता है। फिर इसकी आवश्यकता नहीं है। क्या यह मेरे जावास्क्रिप्ट वेब क्लाइंट के साथ भी ऐसा काम करना चाहिए? मैं इसे बनाने के लिए बैकबोन के साथ नोड.जेएस का उपयोग करना चाहता हूं।

बहुत बहुत धन्यवाद।

EDIT2: वास्तव में एक कोर ब्राउज़र समस्या होने लगता है। मैंने सर्वर पक्ष पर OPTIONS विधि के लिए हेडर एक्सेस-कंट्रोल-अनुमति-विधियों को जोड़ा है और यह क्रोम पर काम करता है। मेरे पास JSON प्रतिक्रिया तक पहुंच नहीं है और अब कोई त्रुटि नहीं है। लेकिन मुझे अभी भी अगले अनुरोधों के लिए प्राधिकरण शीर्षलेख का उपयोग करने की आवश्यकता है। कुकी को भेजने के लिए jQuery को कैसे बताना है?

और जब मैं फ़ायरफ़ॉक्स 11 के साथ प्रयास करें, मैं json प्रतिक्रिया करने के लिए कोई उपयोग कर सकते है और मैं त्रुटि है:

"NetworkError: 401 Non-Autorisé - http://localhost:8087/SpringMVC/users/user1" 
+0

क्या आप अपना उपयोगकर्ता नाम/पासवर्ड बेसकोड कर रहे हैं? –

+0

हां, मैंने इसे वास्तविक उपयोगकर्ता नाम: पासवर्ड के बजाय xxxxxxxx रखा है। – rico

उत्तर

8

जाहिर है, क्रोम और फ़ायरफ़ॉक्स क्रॉस-डोमेन थोड़ा अलग अनुरोध करता है इलाज। क्रॉस डोमेन अनुरोध करने से पहले, वे HTTP विकल्प विधि के साथ 'प्रीफलाइट' अनुरोध कहलाते हैं। क्रोम और फ़ायरफ़ॉक्स के बीच का अंतर यह है कि क्रोम प्रमाणीकरण के साथ प्राधिकरण शीर्षलेख भी भेजता है जबकि फ़ायरफ़ॉक्स नहीं करता है।

फिर, यह एक स्प्रिंग सुरक्षा कॉन्फ़िगरेशन समस्या बनी हुई है। मेरे यूआरएल/उपयोगकर्ता/* विकल्प सहित सभी HTTP विधियों के लिए सुरक्षित है। फ़ायरफ़ॉक्स के मामले में, प्राधिकरण हेडर नहीं भेजा गया है, मेरा अनुरोध अधिकृत नहीं है। अगर मैं केवल अपने सुरक्षित यूआरएल/उपयोगकर्ता/* को जीईटी विधि में प्रतिबंधित करता हूं, तो यह फ़ायरफ़ॉक्स के लिए पूरी तरह से काम करता है।तो मैं केवल यह है कि मेरे स्प्रिंग सुरक्षा config में जोड़ने के लिए किया था:

<intercept-url pattern="https://stackoverflow.com/users/*" access="isAuthenticated()" method="GET"/> 

बाद में, मैं विकल्प है: मैं विकल्प को छोड़कर, अन्य तरीकों अवरोधन-यूआरएल में सुरक्षित किया जा करने के लिए जोड़ सकते हैं, या मैं HTTP प्रतिबंधित कर सकते हैं मेरे स्प्रिंग एमवीसी नियंत्रक में प्राप्त करने के लिए विधि कॉल, जो जावडोक के अनुसार मेरे विकल्प कॉल का भी इलाज करेगा। मैंने दूसरा समाधान चुना। लेकिन अगर किसी को फ़ायरफ़ॉक्स को क्रोम जैसे प्रमाण पत्र भेजने के लिए मजबूर करने का समाधान मिलता है, तो यह बहुत अच्छा होगा और मैं इसे चुनूंगा।

2

स्प्रिंग सुरक्षा विन्यास रीको द्वारा प्रस्तुत किया जाएगा परिदृश्य के लिए एक अन्य विकल्प:

<http ... use-expressions="true"> 
    <intercept-url pattern="https://stackoverflow.com/users/*" access="permitAll" method="OPTIONS"/> 
    <intercept-url pattern="https://stackoverflow.com/users/*" access="isAuthenticated()"/> 
    ... 
</http> 

HTTP विकल्प अनुरोध हमेशा प्रमाणीकरण के माध्यम से पारित होगा और किसी भी अन्य HTTP विधि नहीं होगा।

नोट use-expressions XML विशेषता <http> तत्व में सच करने के लिए सेट। स्प्रिंग सुरक्षा तो <intercept-url> तत्वों की access विशेषताओं को रोकने के लिए स्प्रिंग ईएल भाव, permitAll और isAuthenticated() की तरह उम्मीद होगी।

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