2011-08-23 11 views
7

मेरे पास एक साधारण सवाल है: क्या XMLHTTPRequest के साथ डाइजेस्ट-प्रमाणीकरण का उपयोग करना संभव है?क्या XMLHTTPRequest के साथ डाइजेस्ट-प्रमाणीकरण का उपयोग करना संभव है?

यदि उत्तर नहीं है, तो तकनीकी कारण क्या है? या यदि यह संभव है - मैं यह कैसे कर सकता हूं?

धन्यवाद एक बहुत ... गूगल कोई अच्छा जवाब अब तक नहीं है: -/

संपादित करें:

जवाब के लिए धन्यवाद। पाचन प्रमाणीकरण-योजना से मेल खाने के लिए हेडर को संशोधित करने के बाद, एक गैर-प्राप्त होने के बाद, एक समाधान प्रतीत होता है।

लेकिन मैं वास्तव में क्या देख रहा था कि मैं अपना वर्तमान कॉल बदल सकता हूं: xmlhttp.open ("GET", url, false, username, पासवर्ड); से sth। जैसे कि xmlhttp.open ("GET", url, false, उपयोगकर्ता नाम, पासवर्ड, "DIGEST");

यह मेरे शुरुआती प्रश्न का भी हिस्सा है: ओपन-विधि पाचन-अनुरोध करने का विकल्प क्यों नहीं देता है?

शायद जेएस-लिब कोई सिफारिश कर सकता है जो मुझे ऐसा करने देता है - जैसा कि आप कल्पना करते हैं कि मैं वास्तव में एक और सरल xmlhttp.open को एकाधिक अनुरोधों में बदलना नहीं चाहता हूं और पहले एक गैर-प्राप्त करें।

+0

आपने अभी तक क्या प्रयास किया है? यदि आपके सर्वर पेज को डाइजेस्ट ऑथ (अनधिकृत अनुरोधों के लिए 401 लौटा रहा है) की आवश्यकता है, और आप अपने एक्सएचआर ओपन() कॉल में उपयोगकर्ता नाम और पासवर्ड पास करते हैं, तो सब कुछ ठीक काम करना चाहिए। – EricLaw

+0

क्या आपने इसे किया है? मैं वास्तव में कुछ कोड की सराहना करता हूं। धन्यवाद! – vrunoa

उत्तर

8

आप इसे कोई समस्या नहीं कर सकते हैं। बस आपको लगता है कि चश्मा के हिस्सों का पालन करें;)
http://tools.ietf.org/html/rfc2617
और क्लाइंट पक्ष पर आपकी प्रमाणीकरण लाइब्रेरी
http://pajhome.org.uk/crypt/md5/
लिखना शुरू करने के लिए आप सभी गायब हैं।

पूर्व विनिमय उपयोगकर्ता नाम और पासवर्ड
अरे मैं ----> सर्वर
यहाँ ठीक एक अस्थायी रूप से/नमक ----> ग्राहक
यहाँ है प्रमाणीकरण करना चाहते हैं अपना उपयोगकर्ता नाम की एक MD5 हैश योग है पासवर्ड टाइमस्टैम्प और नमक -----> सर्वर
मैंने आपके पासवर्ड और उपयोगकर्ता नाम को वैसे ही किया है जैसा आपने किया था और वे वही हैं -----> ग्राहक
ये मूल बातें हैं।

मैंने छोड़ा कि आपको हैशसम में अनुरोधित संसाधन के यूआरआई को शामिल करने की आवश्यकता है !!!!
बेशक आप सर्वर पर किसी संसाधन के लिए किए गए हर अनुरोध के साथ ऐसा करते हैं, जिस तरह से हैश को अवरुद्ध करने वाला कोई व्यक्ति केवल आपके द्वारा अनुरोधित सामग्री को देख सकता है और विविध संसाधन के लिए अनुरोध नहीं कर सका। यह विधि डेटा को सुरक्षित नहीं करती है बस इसका उपयोग करें।

+0

मैं असहमत हूं। कोई भी सर्वर के लिए एक nonce के लिए पूछ सकते हैं। आप इसे सुरक्षित रूप से क्लाइंट-साइड में कैसे ट्रांसपोर्ट करना चाहते हैं? – Chielus

+5

आप एमडी 5 से अपना पासवर्ड समझना और प्रत्येक प्रमाणीकरण को अद्वितीय बनाने का प्रयास करना अधिक कठिन नहीं है। http://en.wikipedia.org/wiki/Cryptographic_nonce। इस तरह कोई व्यक्ति आपके पास हैश के बीच में आदमी नहीं कर सकता और फिर किसी अन्य समय इसके साथ प्रमाणित कर सकता है। वास्तव में वे ओथ में एक नॉन का उपयोग करते हैं। मुझे पता है कि आप क्या सोच रहे हैं कि अभी भी पूरी तरह से असुरक्षित है लेकिन इस प्रकार के प्रमाणीकरण का उद्देश्य सिर्फ आपके उपयोगकर्ता नाम और पासवर्ड को सुरक्षित रखना है। यह बहुत बुनियादी है। – Prospero

+0

:/के लिए नीचे वोट क्या था? – Prospero

0

ऐसा करने का सबसे अच्छा तरीका एसएसएल का उपयोग करना है। मुझे नहीं लगता कि कोई अन्य सुरक्षित समाधान मौजूद है (अगर मैं गलत हूं तो मुझे सही करें)

+1

देखें केवल गलत नहीं;) – Prospero

+1

डायजेस्ट बेसिक + एसएसएल से अधिक सुरक्षित है! सुरक्षा पर अनुभाग आरएफसी 2617 देखें। – wprl

+1

एसएसएल के बिना, एक मिटएम हमलावर (उदा। शत्रुतापूर्ण या समझौता प्रॉक्सी; सार्वजनिक वाईफाई एक्सेस पॉइंट पर कहें) HTML पर मनमानी जावास्क्रिप्ट (या बस लिंक) इंजेक्ट कर सकते हैं। इस प्रकार हमलावर के अनुरोध उपयोगकर्ताओं के ब्राउज़र से उत्पन्न होंगे, इस प्रकार सर्वर को यह बताने का कोई मौका नहीं होगा कि ये उपयोगकर्ता से _not_ हैं। हमलावर को पासवर्ड का पता लगाने की भी आवश्यकता नहीं है। – robert4

6

इस आलेख को देखें: http://marcin-michalski.pl/2012/11/01/javascript-digest-authentication-restful-webservice-spring-security-javascript-ajax/। यह बताता है कि सर्वर पक्ष में SpringSecurity के साथ डाइजेस्ट प्रमाणीकरण के लिए जावास्क्रिप्ट क्लाइंट कैसे करें। कोड github में उपलब्ध है: https://github.com/Arrowgroup/JSDigestAuth

+0

यह सबसे अच्छा जवाब है। किसी के पोस्ट को इंगित करते हुए, जिसने सभी काम किए हैं और यह पूर्ण स्रोत कोड प्रदान करता है (इसे परीक्षण करने का एक बहुत ही आसान तरीका है) –

3

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

आपके पास सबसे बड़ा मुद्दा यह है कि पहले सर्वर 401 उत्तर पर किसी भी सबसे अधिक उपयोग किए जाने वाले ब्राउज़र आपके प्रमाण-पत्र प्राप्त करने के लिए एक संवाद बॉक्स खोलेंगे।जहां तक ​​मैंने देखा है कि इसे रोकने के लिए कोई आसान तरीका नहीं है: How can I supress the browser's authentication dialog?

इसे हल करने के लिए, मैंने वेब सर्वर को संशोधित किया जिसे मैंने सी # कोडेप्लेक्स प्रोजेक्ट से कोड किया था। पहले अनुरोध पर क्लाइंट "चेतावनी" शीर्षलेख कहता है "401 उठाएं"। सर्वर चुनौती बनाता है और इसे एक कस्टम, गैर -401 एचटीपीएक्सप्शन के साथ वापस भेजता है (मैं इस पल के लिए 406 का उपयोग करता हूं, जो HTTP में "स्वीकार्य नहीं है")। क्लाइंट हैश बनाता है और इसे वापस भेजता है।

यदि कोई दिलचस्पी लेता है तो मैं कुछ कोड स्निपेट पोस्ट कर सकता हूं, यह एक पुराना सवाल है।

+0

सफारी के लिए यह सच नहीं लगता है, जब इसे XHR पर 401 प्राप्त होता है। – wprl

+0

"इस" से आपका क्या मतलब है? "यह" = "ब्राउज़र एक्सएचआर 401 के लिए भी एक संवाद बॉक्स खोलता है"? यदि ऐसा है, तो चेतावनी हेडर चाल की कोई आवश्यकता नहीं है। व्यापक रूप से संगत समाधानों को अभी भी एक कामकाज की आवश्यकता होगी। – malber

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