Servern kan inte helt lita på data som den tar emot från klienten, så det är svårt att validera höga poäng.

Här är några alternativ:

1. Fördunkla klientsidans kod och trafik till servern. Detta är det enklaste alternativet - det kommer fortfarande att vara möjligt att fuska, men förmodligen kommer det inte att vara värt någons tid.

2. Skicka en fullständig eller delvis återuppspelning av spelet till servern för validering. Spelarens drag kan köras på servern för att bestämma den legitima poängen. Detta fungerar för vissa spel och inte för andra.

3. Flytta spellogiken och valideringen till servern. Klienten vidarebefordrar helt enkelt varje drag till servern, där den valideras och spelets tillstånd uppdateras.

Det handlar om hur ditt spel fungerar, hur sannolikt det är att människor kommer att fuska, och hur mycket du bryr dig om de gör det.

Om din angripare var en man-i-mitten-angripare på nätverkslagret, skulle https vara tillräckligt. Men tyvärr är din angripare klienten, så det här är ganska meningslöst.

Regel nummer ett av fusksäkra spel: Lita aldrig på klienten! Klienten är i fiendens händer.

Javascript-spel körs i användarens webbläsare. Som du som webbutvecklare säkert vet kommer varje webbläsare idag med en inbyggd felsökare som kan visa och ändra alla variabler medan ett program körs. Användaren kan helt enkelt använda felsökaren för att ändra sin poäng innan den skickas. Det finns inget du kan göra för att förhindra det. Med webbläsarbaserade spel kan du inte ens slå ett tredjeparts-anti-fuskverktyg på dem (som är av tvivelaktigt värde och i alla fall etiskt ifrågasatta).

Den enda motåtgärden är att genomföra alla spelmekaniker som är värda att manipulera på servern. Klienten ska inte göra annat än att vidarebefordra användarens kommandon till servern och visualisera spelet baserat på serverns meddelanden. Den faktiska spelningen ska ske på servern där den är utom räckhåll för fuskarna.

Ja, det betyder att du måste omforma ditt spelets programvaruarkitektur från grunden. Det betyder också att du måste lägga till lite förutsägelse och interpolationskod för att göra nätverksfördröjningen mindre synlig. Och det betyder också att du kommer att behöva mycket bättre serverhårdvara och en bättre internetanslutning för din server (s). Men när du vill ha ett fuskfritt onlinespel är det enda alternativet.

För att uppnå säker spelhög poäng behöver du ett " bevis på arbete", eller snarare, mer lämpligt kallat proof of play.

Ett bevis på arbete / spela är alla data som är svåra att beräkna innan du avslutar spelet, men lätt att beräkna när du är klar med spelet och är lätt att verifieras av servern. Till exempel, för ett Sudoku-spel är ett bevis på arbete lösningen på pusslet.

Tyvärr finns det inget generiskt sätt att integrera lämpligt proof of play-system i många spel. Det är inte alltid möjligt att integrera ett bevis på spel utan att justera eller omarbeta spelet, eller begränsa räckvidden för ledartavlan till bara element där du kan inkludera tillräckligt säkert bevis på spel.

Spelbevis på en spelet börjar med att servern utfärdar fröet för spelets RNG. Klienten måste då hitta ett bevis på spelet som matchar det frö som spelaren hade utfärdat. I många spel kan ett bevis på spel skapas genom att skicka spelets lösning till servern med hög poängsändning, i andra kan det vara nödvändigt att spela in hela spelsessionen i olika detaljeringsnivåer beroende på spelet och beviset på spel du använder.

Ett bevis på spel måste vara omspelningsbeständigt (en spelare borde inte kunna använda en annan spelares färdiga spel för att göra sitt eget bevis på spel lättare att beräkna). Detta begränsar bevis på spel till spel där det finns en slumpmässighet att spelare inte bara kan återanvända en annan spelares bevis på spel, men det kan inte heller ha för mycket icke-deterministiskt beteende till den punkt där det blir omöjligt att verifiera spelet. spel är också begränsat. I ett Sudoku-spel är det till exempel inte möjligt att bevisa hur lång tid spelaren tar för att lösa pusslet. Bevis på spel kan inte alltid skilja mellan spel som spelaren spelar och spelaren som har skrivit ett manus som spelade spelet för dem.

Jag ville bara nämna att det finns en slags lösning på detta problem men det är sannolikt inte tillgängligt för dig; lösningen kallas "homomorf kryptering" och det gör det möjligt för en klient att utföra en känd beräkning utan att veta exakt vilka värden de beräknar med, och en server som därför kan kontrollera strukturen för det beräknade värdet för att bevisa att klienten inte bara skicka tillbaka en slumpmässig sträng men byggde den faktiskt ut ur de angivna värdena.

Problemet är att det antingen är långsamt eller ofullständigt , med "ofullständigt" vilket betyder "inte innehåller ett komplett utbud av logiska primitiver." Mycket ofta är det ett partiellt system som tillåter vissa krypterings- och dekrypteringsoperationer E (), D (), plus en del komplicerad operation operation så att

D (E (A) ⊕ E (B)) = A + B,

eller liknande.

Så låt oss se hur detta löser problemet för vissa spel. Tänk på ett spel med "ljus ut" -typ där du trycker på N hexarna i ett sexkantigt rutnät och var och en växlar både dess tillstånd och tillstånden för dem runt det. Detta är en kommutativ algebra för dessa "pressar" och därför kommer det inte att finnas mer än N pressar totalt i en given lösning, plus varje hex beror bara på initialtillståndet plus pressarna på sin egen hex plus de 6 hexorna runt den.

Eftersom vårt homomorfa krypteringsschema endast tillåter +, inte XOR, ger vi varje hex en 3-bitars räknare för det antal gånger den har vänt. (Klientprogramvaran krymper automatiskt varje dubbeltryck av en hex till bara ett tryck.) De faktiska vändningsåtgärderna är därför bitvektorer som ser ut,

  001 001 000 000 000 001 001 001 000 001 001 000 000 ... 000 00000000 00000001  

Med andra ord har de 1s i vart och ett av dessa 3-bitarsfält som den vänder, plus en 1 i någon 16-bitars räknare.

Vi krypterar alla dessa med ett homomorfiskt krypteringsschema, skickar var och en av dem till klienten och klienten skickar tillbaka oss ett krypterat värde beräknat från dessa krypterade värden som vi skickade tillbaka. Vi dekrypterar sedan detta och OCH det dekrypterade värdet med bitsträngen,

  001 001 001 001 ... 001 11111111 00000000  

och jämför med det ursprungliga spelet -stat tillsammans med 0 för de 8 motbitarna.

Om de skickar oss ett slumpmässigt värde är deras chans att vi accepterar det 2 ^{- (N + 8)} och därför deras enda användbara sättet att klara testerna är att använda de värden som vi gav dem i någon tillåten kombination. De har tillgång till vissa drag som vi inte tillåter dem direkt på grund av heltalsspill, men vi kan alltid göra fälten bredare än 3 bitar för att göra dessa dyrare för räknaren till höger. Men vi överfördes aldrig deras enskilda knapptryckningar, mycket mindre omspelning av historien: vi accepterade en vektor som säger "här är hur jag vred på nätet", vilket är den "superosäkra sak" som alla varnar dig för, men vi gjorde det på ett sådant sätt att de inte kan göra de saker vi är oroliga för utan tillgång till en hemlig nyckel. ger inte spontant 1000 röster till Alice.

Allt på klientsidan kan falska. Så svaret är nej.

REDIGERA Jag tog bort säkerhetsmekanismen jag skrev här eftersom den bara försäkrar legitima sessioner ... men falska poäng kan skickas genom legitima sessioner. Tack @Luke Park

Min rekommendation är mer en teknik för förmörkelse och kan möjligen vara ett frustrerande hinder för många användare. Dock kan avancerade eller bestämda användare fortfarande analysera din källkod för att återge resultaten.

Använd ett verktyg som Hashids för att skapa en hash av poängen och skicka detta i din serverförfrågan tillsammans med klartextpoäng. Strängvärdet för användar-id kan vara det salt som används för att koda en hashid av poängen, vilket gör hash värdelös om den delas. På serversidan kan du avkoda denna hash och jämföra resultatet med klartextpoängen som skickades för att se till att de matchar som förväntat.