2010-05-20 17 views
6

पर उपयोगकर्ता नाम और पासवर्ड भेजना मैं एक वेब सेवा विकसित कर रहा हूं और मुझे एक जीईटी विधि में सेवा के लिए उपयोगकर्ता नाम और पासवर्ड भेजना होगा। क्या यह जानकारी यूरी में तब तक भेजना ठीक है जब तक यह एसएसएल जैसे सुरक्षित चैनल पर जा रहा हो? दूसरे शब्दों में, क्या मेरे पास एक यूरी है जो/उपयोगकर्ता/{उपयोगकर्ता नाम}/{cleartext_password} जैसा दिखता है?वेब सेवा

संपादित करें: क्षमा करें, मुझे लगता है कि मैं अस्पष्ट था। वेब सेवा अनिवार्य रूप से केवल उपयोगकर्ता नामों का डेटाबेस है और पासवर्ड धोया है। एक डेस्कटॉप एप्लिकेशन की कल्पना करें जो दूरस्थ डेटाबेस में उपयोगकर्ता नाम और पासवर्ड रखती है। अंतिम उपयोगकर्ता एप्लिकेशन में अपना उपयोगकर्ता नाम और पासवर्ड टाइप करता है और एप्लिकेशन उपयोगकर्ता को प्रमाणीकृत करने के लिए वेब सेवा तक पहुंचता है।

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

उत्तर

0

आम तौर पर यह एक अच्छा विचार नहीं है ... यह डेटा कई लॉग फाइलों में मौजूद होगा, जिसके परिणामस्वरूप डेटा उन लोगों को दिखाई दे सकता है जो इसे नहीं देखना चाहिए। यदि आप कर सकते हैं तो कम से कम आपको इसे भेजने से पहले हैश करना चाहिए या एन्क्रिप्ट करना चाहिए।

यहाँ थोड़ा और विस्तार के लिए एक संबंधित चर्चा है ... Is an HTTPS query string secure?

+0

या आप दो तरह से एसएसएल प्रमाणीकरण कर इस पर गौर कर सकता है।उपयोगकर्ताओं को सर्वरों के समान प्रमाणपत्रों की आवश्यकता होगी, लेकिन सर्वर तब उपयोगकर्ता को सुरक्षित रूप से प्रमाणीकृत कर सकता है। उदाहरण के लिए, – mpez0

0

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

आप जो कर सकते हैं वह पहले वेब सेवा के लिए प्रमाणित है (एसएसएल के माध्यम से एसएसएल के माध्यम से उपयोगकर्ता नाम और पासवर्ड भेजें) और सर्वर से टोकन प्राप्त करें जो इसे पहचान लेगा। फिर प्रत्येक बाद के अनुरोध के साथ उस टोकन भेजें।

+0

Google, आपको अपने एपीआई के लिए एसआईडी पुनर्प्राप्त करने के लिए एसएसएल के माध्यम से अपना उपयोगकर्ता नाम और पासवर्ड भेजने की अनुमति देता है ... फिर आप उस एसआईडी को प्रत्येक बाद के जीईटी अनुरोध के साथ एक कुकी में भेजते हैं। यह ठीक काम करता है। – EAMann

7

ऐसा करें।

एक "कुंजी" और "पाचन" भेजें।

"कुंजी" उपयोगकर्ता नाम के बराबर है।

"डाइजेस्ट" कुंजी, यूआरआई और "साझा रहस्य" या पासवर्ड का एक SHA1 (या MD5) हैश है।

जब सर्वर इसे प्राप्त करता है, तो यह कुंजी, यूआरआई के अनुरोध और "साझा रहस्य" या पासवर्ड के आधार पर डाइजेस्ट के अपने संस्करण की गणना करता है। Digests से मेल खाने में विफलता एक 401 त्रुटि प्रतिक्रिया है।

+0

यह वास्तव में एक बहुत ही सुरुचिपूर्ण समाधान है ... – EAMann

0

एसएसएल यूआरआई को एन्क्रिप्ट करता है, लेकिन निश्चित रूप से कुछ विकल्पों पर नज़र डालें।

HTTP मूल प्रमाणीकरण, अच्छा और सरल है, और अच्छी तरह से ब्राउज़रों, वेबसर्वर द्वारा समर्थित है आदि

यह भी यूआरआई रूप में एक ही डिग्री करने के लिए लॉग फ़ाइलों में नहीं करना पड़ेगा

एनबी: यह सिर्फ कुछ है सादे-पाठ HTTP शीर्षलेख, इसलिए गैर-एसएसएल ऐप्स के लिए निश्चित रूप से अनुशंसित नहीं है।

http://en.wikipedia.org/wiki/Basic_access_authentication