2013-01-07 12 views
7

"क्लैश ऑफ़ क्लांस" किसी मौजूदा दूरस्थ रूप से संग्रहीत गेम स्थिति वाले किसी खिलाड़ी को प्रमाणीकृत और लिंक करने के लिए गेम सेंटर का उपयोग करता है।किसी ऑनलाइन गेम के सर्वर पर गेम सेंटर प्लेयर को प्रमाणीकृत करना

जो मैं देख सकता हूं, एक गेम केवल क्लाइंट साइड पर प्लेयर पहचानकर्ता प्रदान करता है। क्या पहचानकर्ता को भेजने के बजाय उपयोगकर्ता को सुरक्षित रूप से प्रमाणीकृत करने के लिए एक समर्थित तकनीक है (जो केवल उपयोगकर्ता नाम के साथ प्रमाणीकरण के बराबर है)?

+1

इस प्रश्न का उत्तर है: http://stackoverflow.com/questions/15755489/setting-up-third-party-server-to-interact-with-game-center –

उत्तर

0

चूंकि आप अपने सर्वर से प्रमाणीकरण कर रहे हैं, यह आपके क्लाइंट और आपके सर्वर के बीच लागू करने के लिए कुछ है। खेल केंद्र आपकी मदद करने में सक्षम नहीं होगा।

एक साधारण विचार playerID से एक हैश की गणना करने के लिए होगा जो केवल आप जानते हैं, और सर्वर की तुलना क्लाइंट द्वारा की जा रही चीज़ों की तुलना में करें।

जब आपका क्लाइंट पहली बार चलता है तो यादृच्छिक कुंजी उत्पन्न करने से बचें, क्योंकि जब क्लाइंट पुनः स्थापित होता है, तो उपयोगकर्ता लॉक हो जाएगा।

+0

दरअसल, यह एक तरीका है .. किसी को धीमा करो। एक जेलब्रोकन डिवाइस आसानी से एक अलग खिलाड़ी आईडी को वापस करने में धोखा दिया जा सकता है - यही कारण है कि मैं कुछ और सुरक्षित क्यों पूछ रहा हूं। और क्लैश ऑफ क्लैंस जैसे गेमों पर विचार करने से गेम सेंटर-अकाउंट से जुड़े आईएपी होते हैं, यहां तक ​​कि जोखिम में भी पैसा होता है - और यही चिंता है कि मैंने पूछा। सर्वर साइड ऑथ चेक की तरह लगता है एक रडार के लिए एक अच्छा उम्मीदवार है: - / –

1

चूंकि मैंने सवाल पूछा, ऐप्पल ने एक नई एपीआई पेश की है और उत्तर इस पर उपलब्ध है: Setting up third-party server to interact with Game Center (धन्यवाद, उपयोगकर्ता 2 9 4 9 75 9) और कुछ अन्य स्थानों पर।

Specifically, iOS 7 (Apple documentation on Wayback Machine) के बाद से:

-[GKLocalPlayer generateIdentityVerificationSignatureWithCompletionHandler:]

एक हस्ताक्षर है कि एक तीसरी पार्टी सर्वर स्थानीय खिलाड़ी को प्रमाणित करने के लिए अनुमति देता है उत्पन्न करता है।

प्रासंगिक कॉलबैक ब्लॉक के तर्कों NSURL *publicKeyUrl, NSData *signature, NSData *salt, uint64_t timestamp शामिल हैं। ये, प्लेयर के playerID और bundleID के साथ, सर्वर को 'लॉगिन जानकारी' के रूप में भेज दिया जाना चाहिए।

  • इस बिंदु पर, एक, serverside, publicKeyURL का उपयोग सार्वजनिक कुंजी
  • serverside प्राप्त करने के लिए करना चाहिए, सत्यापित करें कि यह सार्वजनिक कुंजी एप्पल द्वारा हस्ताक्षर किए गए हैं
  • serverside, CONCATENATE UTF-8-एन्कोडेड playerID, bundleID, बड़े endian uint64 टाइमस्टैम्प, और शब्दशः salt
  • serverside, उत्पन्न SHA-256 से ऊपर की digest
  • serverside निर्माण करने के लिए, सत्यापित करें signature है कि सर्वर के लिए भेज दिया गया था, पहले डाउनलोड सार्वजनिक कुंजी, signature और digest

वहाँ एक example in pseudo-PHP है, एक example of how one would implement this in Objective-C (जो थोड़ा समझ में आता है शब्दशः उपयोग करने के लिए), एक Go implementation, सही है using एक Ruby implementation और उसी प्रश्न पर अन्य भाषाओं में कार्यान्वयन का वर्गीकरण है।

अनजाने में, गो में कार्यान्वयन विशेष रूप से पठनीय लगता है, लेकिन यह सत्यापित नहीं करता है कि ऐप्पल द्वारा सार्वजनिक कुंजी जारी की गई थी। लिंक्ड रूबी कार्यान्वयन में ऐसा करने का एक स्पष्ट उदाहरण है।

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