ब्राउज़र / एचटीएमएल 5 गेम के लिए एंटी-चीट जावास्क्रिप्ट


35

मैं js / html5 में एक एकल खिलाड़ी एक्शन आरपीजी बनाने पर विचार कर रहा हूं, और मैं धोखा देना बंद करना चाहूंगा। मुझे 100% सुरक्षा की आवश्यकता नहीं है, क्योंकि यह एक मल्टीप्लेयर गेम नहीं है, लेकिन मैं कुछ स्तर की सुरक्षा चाहता हूं।

तो आप क्या रणनीतियों के बारे में सुझाव देते हैं जो छोटा और औचित्य से परे हैं?

मैं कुछ सर्वर साइड को सरल जाँच करने के लिए परेशान नहीं करूँगा, लेकिन मैं अपने सभी गेम स्टेट्स को सर्वर साइड पर रखते हुए डियाब्लो 3 पथ पर नहीं जाना चाहता।

चूंकि यह एक प्रकार का आरपीजी बनने जा रहा है, इसलिए मैं एक सांख्यिकी निरीक्षक बनाने के विचार के साथ आया हूं जो उनके मूल्यों में अचानक परिवर्तन की जांच करता है, लेकिन मुझे यकीन नहीं है कि यह कैसे सुसंगत और भरोसेमंद है।

चर और कार्यों के एस्कॉप्स के बारे में क्या? जब भी संभव हो छोटे एस्कॉप्स पर काम करना अधिक सुरक्षित है, लेकिन यह प्रयास के लायक है?

वहाँ वैसे भी जावास्क्रिप्ट के लिए आत्म निरीक्षण यह एक चेकसम की तरह पाठ है?

ब्राउज़र विशिष्ट समाधान हैं? मैं इसे केवल शुरुआती बिल्ड में क्रोम के लिए प्रतिबंधित करने की जहमत नहीं उठाऊंगा।


आपका डेटा कहाँ सहेजा गया है, आपका डेटा कैसे सहेजा गया है?
डॉगडॉग सेप

अजीब बात है कि आप डायबल 3 के बारे में बात करते हैं, "डियाब्लो 1 रास्ता" बिल्कुल यही था, क्लाइंट पर भरोसा करना। यदि आप उस वजह से याद रखने के लिए बहुत कम उम्र के हैं तो एक Google खोज करें!
वाल्डम


Apoc, अभी मेरे पास अवधारणा का एक प्रमाण है और मैंने किसी भी प्रकार की दृढ़ता को लागू नहीं किया है - लेकिन मेरी योजना है कि मैं पहले बिल्ड और / या स्थानीय भंडारण में कुछ DB दृढ़ता को लागू करने की योजना बनाऊं ताकि खिलाड़ी केवल वहीं से खेलते रहें जहां उन्होंने छोड़ा था। हां, वाल्डोंड मैं ने तब डियाब्लो के अपने हिस्से को निभाया। लेकिन मैं एक प्रतिस्पर्धी मल्टीप्लेयर गेम, या एक पूर्ण ध्वजांकित एएए का निर्माण नहीं कर रहा हूं। बाइट 56, मुझे अपने कोड को चोरी करने से कोई सरोकार नहीं है (जो किसी भी तरह से उस बकवास को चाहेगा?)
बिली निंजा

दुर्भाग्य से, आपको डायब्लो 3 पथ पर जाना होगा, अगर आप वास्तव में हैक / धोखा देने के बारे में चिंतित हैं
Noob Game Developer

जवाबों:


46

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

अच्छी खबर यह है कि, आम तौर पर, एकल-खिलाड़ी खेलों में बहुत कम धोखा होता है। लाइन राइडर जैसे बड़े "यूट्यूब हाईस्कोर" समुदायों वाले खेलों के लिए एकमात्र प्रमुख अपवाद है, जहां खिलाड़ी YouTube पर एक-दूसरे के साथ प्रतिस्पर्धा करते हैं।

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

काश, इसका बेहतर जवाब होता, लेकिन ऐसा नहीं है।

उस ने कहा, ऐसी चीजें हैं जो आप इसे धोखा देने के लिए थोड़ा कठिन बना सकते हैं। वे इसे करने से किसी को गंभीर नहीं रोकेंगे और धोखा देने के लिए टूलकिट जारी करेंगे, लेकिन यह उन्हें धीमा कर देगा:

  • अपने JS को Minify और Obfuscate करें, जो बिल्कुल कोड को पढ़ने में कठिन बना देगा। आप डी-ऑबिफिकेट को डी-मिनिफाई और सॉर्ट कर सकते हैं, लेकिन आप कभी भी सही वेरिएबल और फंक्शन के नाम वापस नहीं ले सकते, न ही कमेंट।
  • एक अलग भाषा के साथ मूल्यों में सेंकना। इस मामले में आप स्थैतिक सेटअप चर को संभालने के लिए PHP या अन्य सर्वर साइड भाषाओं का उपयोग कर सकते हैं। यदि कूद की दूरी को हमेशा 2 स्थान माना जाता है, तो आमतौर पर आप खिलाड़ी ऑब्जेक्ट के लिए एक कूद दूरी को परिभाषित करेंगे। मत संभालो, PHP के साथ इतना है कि जेएस स्रोत 2s के साथ समाप्त हो जाता है एक लाख स्थानों में कोड भर में पलटा। यह आपके जेएस को भी गति देने में सक्षम होने का सुखद अतिरिक्त दुष्प्रभाव है।
  • कुछ अभ्यास के साथ, आप मिश्रण के साथ कुशल हो जाएंगे और आप प्रत्येक खिलाड़ी के लिए अपने जेएस को कस्टम-बिल्ड भी कर सकते हैं। जो धोखाधड़ी को रोकने का एक और तरीका है। यदि प्रत्येक खिलाड़ी का कोड किसी भी तरह से अलग है, तो एक धोखा लिखना मुश्किल है जो टूलकिट का हिस्सा हो सकता है।
  • अंत में, आप खिलाड़ी की पहचान के आधार पर स्रोत की जांच कर सकते हैं। उनका IP पता और / या उपयोगकर्ता नाम कहें। आपको पता है कि जेएस का खिलाड़ी-विशिष्ट संस्करण क्या होगा, आप एक चेकसम में सेंकना कर सकते हैं और आवश्यकता होती है कि यह दूसरे छोर पर समान हो। किसी भी क्लाइंट-साइड जेएस की तरह अक्षम करना आसान है, लेकिन एक बार फिर टूलकिट बनाने के लिए यह थोड़ा कठिन है।

इसलिए। जैसा कि आप देखते हैं, इस मार्ग पर जाने के लिए शायद यह लायक नहीं है। वह कठिन है। वास्तव में मूर्खतापूर्ण कोडिंग प्रथाओं की बहुत आवश्यकता है, और अंततः हार के लिए अपेक्षाकृत आसान है। धोखाधड़ी को रोकने के लिए आपको सभी गणना सर्वर-साइड करने की आवश्यकता होगी। या जाने दो, और स्वीकार करो कि धोखा होगा।


लाइन-राइडर उदाहरण वास्तव में सर्वर-साइड करने के लिए काफी तुच्छ है, उपयोगकर्ता को वह नक्शा अपलोड करने की अनुमति देकर / उसने स्कोर की गणना की है। लेकिन आर्केड जैसे गेम व्यापक कार्य के बिना स्कोर सर्वर-साइड की गणना करने के लिए असंभव हैं।
orlp

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

14

मैंने पहले से ही इस तरह के एक सवाल का जवाब दिया , और मुझे यह बताने के लिए खेद है लेकिन:

मैं कुछ सर्वर साइड को सरल जाँच करने के लिए परेशान नहीं करूँगा, लेकिन मैं अपने सभी गेम स्टेट्स को सर्वर साइड पर रखते हुए डियाब्लो 3 पथ पर नहीं जाना चाहता।

क्या आप यहां कह सकते हैं कि सबसे बुरी बात है। यदि आप "एंटी-चीट" इंजन करना चाहते हैं, तो आपको वह करना होगा। आप सर्वर-साइड कार्य को सुविधाजनक बनाने के लिए क्लाइंट-साइड में कुछ भी जोड़ सकते हैं, लेकिन आपको क्लाइंट पर कभी भी भरोसा नहीं करना चाहिए। आपके पास मौजूद सभी तर्क कम से कम सर्वर-साइड होने चाहिए। यदि आप चाहें तो आप इसे क्लाइंट-साइड पुन: उत्पन्न कर सकते हैं, लेकिन कोई क्लाइंट-साइड केवल समाधान नहीं करेगा।

और वैसे भी, यदि आप अपने प्रोग्राम की कमजोरी का पता लगाना चाहते हैं, तो इसे बाधित न करें, लोगों को अपना कोड देखने दें और आपको बताएं "यहाँ, आपके पास एक मुद्दा है"।

आपके लिए, आपके कोड के लिए, आपके उपयोगकर्ताओं के लिए और समुदाय के लिए यह अच्छा है।


3
सर्वर प्राधिकरण के लिए +1, यदि आप क्लाइंट पर भरोसा करने की कोशिश करते हैं तो यह सिर्फ काम नहीं करता है ...
वालमंड

क्लाइंट-साइड चीजों को पुन: पेश करना खतरनाक है। इससे भी सावधान रहें, क्योंकि यदि सब कुछ क्लाइंट-साइड दोहराया जाता है, तो उपयोगकर्ता सर्वर के साथ चेक डिस्कनेक्ट करके धोखा दे सकता है। वे तब गेम खेल सकते हैं, वीडियो रिकॉर्ड कर सकते हैं और YouTube स्टार बन सकते हैं। यह केवल एकल-खिलाड़ी गेम पर लागू होता है, जो कि यह गेम होगा।
DampeS8N

जब मैं क्लाइंट-साइड के बारे में बात करता हूं, तो यह "आंदोलनों की गणना", "टकराव" आदि के लिए है ... यह दोनों पक्षों को एक मल्टीप्लेयर गेम के लिए भी किया जा सकता है। सर्वर-साइड गणना को हमेशा प्राथमिकता माना जाना चाहिए, लेकिन यह तब मदद कर सकता है जब सर्वर-लेटेंसी में भी क्लाइंट-साइड हो। लेकिन हर चीज के लिए जो "चेक चीट" लॉजिक है, तो मैं मानता हूं कि सब कुछ सर्वर-साइड होना चाहिए।
dardardump

हाँ, मुझे वह मिल गया। लेकिन मैं इस परियोजना को एक शौक के रूप में कर रहा हूं जो मेरे पास खाली समय में है। इस तरह के सर्वर की जाँच करने से परियोजना की जटिलता बहुत अधिक हो जाएगी, जिससे यह न के बराबर हो जाएगा। ठीक है, मैं यह जानकर इस परियोजना को आगे बढ़ाता रहूँगा, और अगर यह मेरे द्वारा कुछ गंभीर सर्वर साइड कंट्रोलिंग के साथ बड़ा और गंभीर होने लगे, तो शायद Node.js.
बिली निंजा

यह OP
Noob Game Developer

3

खैर, शुरू करने के लिए एक अच्छी जगह ऑब्जेक्ट.फ्रीज फ़ंक्शन का उपयोग करना है (जो ऑब्जेक्ट पैचिंग के खिलाफ सुरक्षा को सक्षम करेगा)।

यह "नई संपत्तियों को जोड़े जाने से रोकता है", "मौजूदा गुणों को हटाए जाने से रोकता है", "मौजूदा गुणों को रोकता है, या उनकी गणना, कॉन्फ़िगरेशन, या लेखन क्षमता को परिवर्तित होने से रोकता है"; आंतरिक स्थिति में कोई भी परिवर्तन अभिगमकर्ताओं के माध्यम से किया जाना चाहिए। निम्नलिखित उदाहरण क्रोम पर काम करता है (फ़ायरफ़ॉक्स पर काम करना चाहिए, मुझे IE के बारे में पता नहीं है ...):

var b = {}
// Fill your object with whatever you want
b.a = "ewq"
// Freeze all changes
Object.freeze(b)
// Try to put new value. This wont throw any error, put wont work either, 
// as we shall see ...
b.b = "qwe"

// Values 
console.log(b.a); // outputs "eqw"
console.log(b.b); // outputs  undefined

5
यहां तक ​​कि यह केवल एक निर्धारित चीटर को धीमा कर देगा। यदि और कुछ नहीं तो वह स्रोत को चुरा सकता है, उसे अपनी मशीन पर होस्ट कर सकता है, और फ्रीज कोड को हटा सकता है, और फिर अपने ब्राउज़र को धोखा देने के लिए अपने होस्ट फ़ाइल का उपयोग करके सोच सकता है कि नया पृष्ठ पुराना है, इसे सर्वर से पुनः कनेक्ट कर रहा है।
DampeS8N 14

@ DampeS8N हां, मुझे लगता है कि आप सही हैं।
fableal

जैसा मैंने ओपी में कहा था, मैं बस कुछ स्तर की सुरक्षा चाहता हूं ।
बिली निंजा

यह बिल्कुल मदद नहीं करेगा! उपयोगकर्ता पहले जेएस फ़ंक्शन में डीबगर ब्रेकपॉइंट सेट कर सकता है जो Object.freeze = function(o) {};जेएस कंसोल में निष्पादित और दर्ज होता है।
फिलिप

2

दुर्भाग्य से, आपको डायब्लो 3 पथ पर जाना होगा, यदि आप वास्तव में हैक / धोखा देती हैं। यदि आप नहीं हैं, तो बुनियादी जाँच आपको करनी चाहिए या इसकी दृढ़ता से सलाह दी जानी चाहिए।

  • चेक खरीदें - अगर मैं कुछ खरीद रहा हूं, तो मेरे पास पर्याप्त सोना होना चाहिए
  • sellchecks - अगर मैं कुछ बेच रहा हूं, तो मुझे अपनी इन्वेंट्री ट्रेड चेक में उस वस्तु को बेचने की आवश्यकता है - हथियार बेचने के समान
  • सुसज्जित चेक - अगर मैं एक हथियार लैस कर रहा हूं, तो क्या मेरे पास इसका मालिक है / है?
  • क्षति की जाँच - अगर मैं किसी चीज़ (दुश्मन) पर हमला कर रहा हूँ, तो मैं अपने हथियार से होने वाले अधिकतम नुकसान से अधिक नहीं मार सकता (यहाँ आपको ग्राहक से यह बताने की उम्मीद नहीं करनी चाहिए कि उसने कौन से हथियार का इस्तेमाल किया है क्योंकि यह पहले ही होना चाहिए था)
  • चेकिंग क्राफ्टिंग - अगर मैंने कुछ तैयार किया है, तो क्या मुझे सभी अवयवों / घटकों की आवश्यकता है?

... और इसी तरह

1 बिंदु थोड़ा मुश्किल है, नायक की स्थिति है, क्योंकि आप इसके बारे में बहुत चिंतित नहीं हैं कि आप इसे छोड़ सकते हैं, लेकिन इसका बेहतर आप यह भी करते हैं कि नीचे की तरह एक न्यूनतम जांच के साथ

  • मैं प्लेस 1 @ टी 1 पर हूं, मैं प्लेस 2 टी 2 पर हूं, प्लेस 1 से प्लेस 2 तक यात्रा करने के लिए न्यूनतम समय क्या है और यह मेरे टी 2 - टी 1 से मेल खाता है। आप मानचित्र के आकार के आधार पर इसे छोटे से बड़े तक मैप कर सकते हैं। आपके पास कम से कम प्रमुख क्षेत्रों की सूची होनी चाहिए, जैसे NPC - बॉस, NPC - दुश्मन स्पॉन क्षेत्र (जरूरी नहीं कि सटीक स्थान)

आशा है कि यह मदद करता है, यह मुश्किल लगता है लेकिन आपको वास्तविक काम करने वाले खेल बनाने के लिए सीखने की जरूरत है


बहुत बढ़िया जवाब! मैं सर्वर चेकिंग को लागू करने के तरीके पर एक प्रश्न लिख रहा था, बस मोटे तौर पर मापने के लिए कि सर्वर चेकिंग को लागू करना कितना कठिन है। तुम देखो, मैं एक MMO की तरह रीढ़ की हड्डी को लागू करने के दर्जनों घंटे बर्बाद नहीं करना चाहता और दिन के अंत में यह अभी भी आसानी से कुछ ग्राहक अनुरोध पैरामीटर या ऐसा कुछ ओवरराइड करके आसानी से धोखा देने योग्य है। या बस अधिक शांत सुविधाओं या पॉलिश चीजों को वितरित करने के बजाय सुरक्षा पर केवल एक मजेदार गेम बनाने का प्रयास करना चाहिए।
बिली निंजा

1

मूल रूप से यह संभव नहीं है। धोखा देने से रोकने के लिए आप जो कुछ भी डालते हैं उसके आसपास काम करना इतना आसान होगा।

बात किसी भी सॉफ्टवेयर के साथ है जिसे आप वितरित करते हैं लोग इसे स्मृति में आसानी से संशोधित कर सकते हैं।

इसके अलावा अगर वे धोखा देना चाहते हैं, तो उन्हें जाने दें। वे सिर्फ अपने लिए खेल को बर्बाद कर रहे हैं। इस स्थिति में धोखा देने के लिए कोई वास्तविक व्यावहारिक उपयोग नहीं है, आप बस अपने लिए गेमप्ले को नष्ट कर देंगे।


1

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

Dampes8n ने अलग-अलग स्रोत संस्करणों का उपयोग करने के बारे में जो कहा है, उसके साथ आप इसका उपयोग कर सकते हैं, कि यदि आप बहुत सारे अलग-अलग संस्करणों को उत्पन्न करने का तरीका जान सकते हैं, ताकि प्रत्येक उपयोगकर्ता प्रत्येक बार पूरी तरह से भिन्न स्रोत संस्करण चला रहा हो, जो विफल हो रहा है उस स्रोत संस्करण को भी ब्लैक लिस्ट करें, यह भी कि वह कभी भी उस स्रोत संस्करण के लिए सही आइटम जानकारी नहीं देगा।

इसका मुख्य कारण यह होगा कि यदि किसी हैकर को पहली बार हैक करने का अधिकार नहीं है, तो इससे उन्हें हैक को संशोधित करने में बहुत मुश्किल होगी, क्योंकि हर बार जब हैक पूरी तरह से काम नहीं करता है, तो उन्हें अपने आईपी को बदलें और नए स्रोत संस्करण के लिए फिर से हैक लिखें।


मैं सावधान रहूंगा। आखिरी चीज जो आप करना चाहते हैं वह गलती से एक भुगतान करने वाले ग्राहक की अनुमति है।
जॉन मैकडॉनल्ड्स

@ जॉनमनडोनल्ड ट्रू, वह। शायद सिर्फ उस स्रोत संस्करण को मार रहा है। इस तरह अगर वे गलती से जाल को ट्रिगर करते हैं, तो उन्हें बस ब्राउज़र को रीफ्रेश करना होगा, जबकि अभी भी हैकर्स अपने सभी हैक को फिर से बना सकते हैं।
AJMansfield 19

0

हाँ, यह पूरी तरह से नहीं किया जा सकता है। सर्वर पर हमेशा जाँच करें। कुछ भी जो खेल पर प्रभाव डालता है, उसे सर्वर से प्राधिकरण की आवश्यकता होनी चाहिए।

यही वह विस्तार है जिसके लिए मैं अन्य उत्तर दोहराऊंगा।

हालाँकि, हम केवल सर्वर पर जाँच करने की तुलना में धोखा को रोकने के अंत में बहुत कुछ कर सकते हैं। खैर, हमें कुछ विशेष सर्वर जांचों को जोड़ना पड़ सकता है। हालांकि, ध्यान रखें कि क्लाइंट साइड चेक बेकार नहीं हैं, वे बैंडविड्थ और सर्वर काम को बचाते हैं, जब थिएटर शामिल नहीं होते हैं।

उस के साथ कहा:

  • किसी न किसी क्लाइंट को कम करें: HTTPS पर काम करें, क्रॉस-ओरिजनल रिसोर्स शेयरिंग (CORS) का उपयोग करें, केवल एक ही मूल की अनुमति दें, सब-सोर्स अखंडता का उपयोग करें। मैं सभी अनुरोधों पर इसे लागू करने के लिए एक सेवा कार्यकर्ता को लागू करने का सुझाव देता हूं, जिसका अर्थ यह भी होगा कि खेल इसे केवल HTTP पर स्थानांतरित करने से काम नहीं करेगा (क्योंकि HTTPS के बिना कोई सेवा कार्यकर्ता नहीं है, सर्वर कार्यकर्ता क्लाइंट का हिस्सा है कोर और सर्वर को कोर की उम्मीद है), और अगर वे HTTPS पर काम करते हैं तो यह काम नहीं करेगा क्योंकि सर्वर अन्य मूल को अस्वीकार कर देगा।
  • स्क्रिप्टिंग स्क्रिप्टिंग: प्रमाणीकरण का उपयोग करें और किसी भी कार्य को करने के लिए एक टोकन की आवश्यकता होती है। प्रत्येक अद्यतन चक्र सर्वर को क्लाइंट को एक नया टोकन देना चाहिए, और टोकन जो कुछ भी करता है उसका उपभोग करता है ... कुछ भी करने के लिए एक वैध टोकन की आवश्यकता होती है, टोकन हमेशा बदलता रहता है, और इस प्रकार अनुमान लगाने के लिए व्यवहार्य नहीं है, और यदि ग्राहक एक ही टोकन दो बार भेजता है या एक गलत टोकन भेजता है सर्वर जानता है कि कुछ ऊपर है। अतिरिक्त सुरक्षा के लिए: एक गुप्त कुंजी के साथ टोकन का एक संदेश प्रमाणीकरण कोड (मैक) बनाएं और इसे टी कुकी में जोड़ें। कुकी को संशोधित करना सत्र को मार देगा (और उन्हें कुंजी का अनुमान लगाने की आवश्यकता है), और टोकन को संशोधित करने से मैक की जांच विफल हो जाएगी।
  • कोड को संशोधित करें: सबस्रोत अखंडता के अलावा (जो आधुनिक ब्राउज़र रनटाइम में भी जांच करेगा), अपने चरों को एक सीमित दायरे में रखें (लेट, सेल्फ एक्जीक्यूटिंग अनाम फ़ंक्शंस और जावास्क्रिप्ट मॉड्यूल का उपयोग करके)। इसके अलावा, DOM पर भरोसा न करें (DOM केवल IO के लिए है, स्टोरेज के लिए नहीं, अगर आपको अपनी DOM ऑब्जेक्ट्स को लपेटने और उन्हें रैपर में जोड़ने के लिए विशेषताओं को संलग्न करने की आवश्यकता है)। इस तरह, आप कंसोल पर जो कुछ भी खेल तर्क तक पहुंचने में सक्षम नहीं होना चाहिए (जब तक कि आप कुछ ब्राउज़र भेद्यता का फायदा नहीं उठाते)। आप डेवलपर टूल का पता लगाने के लिए तकनीकों का उपयोग करने पर विचार कर सकते हैं (ये प्रति ब्राउज़र विशिष्ट हैं, और सभी मामलों में काम नहीं कर सकते हैं या भविष्य में काम करना बंद कर सकते हैं ... इस प्रकार, यह एक हथियार दौड़ है)।
  • कुछ ऊपर है? क्या सत्र टूट गया? वर्तमान मैच से खिलाड़ी को किक करें, फिर से लॉगिन करने का अनुरोध करें। एक कैप्चा पर विचार करें ... जिसमें उपयोगकर्ता को यह बताने का भी लाभ है कि "हम जानते हैं कि कुछ दुर्लभ चल रहा है" (यह एक यादृच्छिक सर्वर विफलता नहीं थी), और हाँ, यह शमन का एक रूप है। ओह, और इन लॉग करने के लिए धूमिल न करें। आपको यह सत्यापित करने में सक्षम होने की आवश्यकता है कि वे क्यों हुए, दोनों झूठी पोस्ट को रोकने और समर्थन टिकट का जवाब देने के लिए।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.