अपने सॉफ़्टवेयर के वितरण वास्तव में समस्या की जड़ है।उपयोगकर्ता नामों और पासवर्ड को हशिंग करना और सॉफ़्टवेयर में उन्हें संग्रहीत करना गैर-धोए गए मानों को संग्रहीत करने से कहीं अधिक उपयोगी नहीं है, क्योंकि कोई भी API सर्वर तक पहुंचने के लिए काम करेगा। यदि आप अपने उपयोगकर्ताओं के लिए उपयोगकर्ता नाम और पासवर्ड लागू करने जा रहे हैं, तो मुझे लगता है कि आप सॉफ्टवेयर में मूल्यों को संग्रहीत किए बिना एपीआई नियंत्रण में प्री-कर्सर के रूप में इसका उपयोग कर सकते हैं। मुझे इसे दो भागों में वर्णित करने दें।
अनुरोध हस्ताक्षर
एपीआई अनुरोध सत्यापन के लिए उपयोग में सबसे आम तरीका अनुरोध हस्ताक्षर है। असल में, किसी एपीआई सर्वर पर अनुरोध भेजने से पहले, अनुरोध में पैरामीटर सॉर्ट किए जाते हैं, और मिश्रण में एक अनन्य कुंजी जोड़ दी जाती है। पूरे लॉट का उपयोग तब हैश बनाने के लिए किया जाता है, जो अनुरोध में संलग्न होता है। उदाहरण के लिए:
public static function generateRequestString(array $params, $secretKey)
{
$params['signature'] = self::generateSignature($params, $secretKey);
return http_build_query($params,'','&');
}
public static function generateSignature($secretKey, array $params)
{
$reqString = $secretKey;
ksort($params);
foreach($params as $k => $v)
{
$reqString .= $k . $v;
}
return md5($reqString);
}
आप एक API अनुरोध क्वेरी स्ट्रिंग सभी मापदंडों आप भेजना चाहते थे की एक सरणी के साथ generateRequestString() विधि को फोन करके बस उपरोक्त कोड का उपयोग कर बना सकते हैं। गुप्त कुंजी कुछ ऐसा है जो एपीआई के प्रत्येक उपयोगकर्ता को विशिष्ट रूप से प्रदान किया जाता है। आम तौर पर आप अपने उपयोगकर्ता आईडी को हस्ताक्षर के साथ एपीआई सर्वर में पास करते हैं, और एपीआई सर्वर स्थानीय आईडी से अपनी गुप्त कुंजी लाने के लिए आपकी आईडी का उपयोग करता है और उसी तरीके से अनुरोध को सत्यापित करता है जिसे आपने बनाया है। यह मानते हुए कि कुंजी और उपयोगकर्ता आईडी सही हैं, उपयोगकर्ता सही हस्ताक्षर उत्पन्न करने में सक्षम एकमात्र व्यक्ति होना चाहिए। ध्यान दें कि एपीआई अनुरोध में कुंजी कभी पारित नहीं होती है।
दुर्भाग्यवश, इसके लिए प्रत्येक उपयोगकर्ता को एक अनूठी कुंजी की आवश्यकता होती है, जो आपके डेस्कटॉप ऐप के लिए एक समस्या है। जो मुझे दो कदम उठाने के लिए प्रेरित करता है।
टेम्पोरल कुंजी
तो तुम आवेदन के साथ कुंजी वितरित कर सकते हैं नहीं है क्योंकि यह decompiled जा सकता है, और चाबी बाहर निकलना होगा। इसका मुकाबला करने के लिए, आप बहुत कम रहने वाली चाबियाँ बना सकते हैं।
मान लें कि आपने डेस्कटॉप ऐप का एक हिस्सा लागू किया है जो उपयोगकर्ताओं को उनके उपयोगकर्ता नाम और पासवर्ड के लिए पूछता है, तो आप एप्लिकेशन को अपने सर्वर पर प्रमाणीकरण अनुरोध कर सकते हैं। एक सफल प्रमाणीकरण पर, आप प्रतिक्रिया के साथ एक अस्थायी कुंजी वापस कर सकते हैं, जिसे डेस्कटॉप ऐप अधिकृत सत्र के जीवनकाल के लिए स्टोर कर सकता है, और API अनुरोधों के लिए उपयोग कर सकता है। चूंकि आपने उल्लेख किया है कि आप SSL का उपयोग नहीं कर सकते हैं, यह प्रारंभिक प्रमाणीकरण सबसे कमजोर हिस्सा है, और आपको कुछ सीमाओं के साथ रहना होगा।
लेख एंडी ई सुझाव दिया गया एक अच्छा दृष्टिकोण है (मैंने इसे वोट दिया)। यह मूल रूप से एक अल्पकालिक कुंजी स्थापित करने के लिए एक हैंडशेक है जिसे प्रमाणित करने के लिए उपयोग किया जा सकता है। हस्ताक्षर हैशिंग के लिए एक ही कुंजी का उपयोग किया जा सकता है। आप अपनी संभावनाएं भी ले सकते हैं और उपयोगकर्ता नाम/पासवर्ड को अनएन्क्रिप्टेड भेज सकते हैं और एक अस्थायी कुंजी प्राप्त कर सकते हैं (यह केवल एक बार होता है), लेकिन आपको यह पता होना होगा कि इसे स्नीफ किया जा सकता है।
सारांश
आप एक अस्थायी सत्र कुंजी स्थापित कर सकते हैं, तो आप क्लाइंट प्रोग्राम है कि decompiled किया जा सकता है में कुछ भी स्टोर करने के लिए नहीं होगा। आपके सर्वर पर एक बार भेजा गया उपयोगकर्ता नाम/पासवर्ड उसको स्थापित करने के लिए पर्याप्त होना चाहिए। एक बार आपके पास यह कुंजी हो जाने के बाद, आप डेस्कटॉप ऐप्स में अनुरोध बनाने और API सर्वर पर अनुरोध सत्यापित करने के लिए इसका उपयोग कर सकते हैं।
ऐसा लगता है कि मैं वास्तव में क्या देख रहा हूं। धन्यवाद! –