Dette er mer et system design spørsmål / utfordring, enn en koding spørsmålet.
I utgangspunktet, jeg tenker på å kaste sammen et Bejeweled esque spillet på Facebook med bare HTML, CSS og Javascript. Dette er for det meste ut av et ønske om å lære alle de små begrensninger av FBJS via en ikke-triviell prosjektet.
Så her er greia. Ved utvikling for Facebook, selve API-kall er svært dyre; Ikke bare er det et ekstra innlegg til Facebook servere, det er også api kall grensen og strupe å bekymre seg for. I et nøtteskall, jo færre samtaler til Facebook bedre. Kombiner dette med timing bekymringene til selv dette enkle puslespillet, og det er god grunn til å aggressivt redusere antall tilbakeanrop generelt.
Ikke å være en sikkerhetsekspert, her er design jeg har kommet opp med:
- Bygge inn en tilfeldig frø i spillet siden.
- Bruk som frø for å skape spillebrettet (så vel som andre stykker som nødvendig).
- Tweak frøet (XOR, sette sammen og hasj, noe sånt) etter hver spiller trekk, basert på tid siden siste trekk. Edit: Jeg bør nok også inkludere den faktiske farten tatt i mutere frøet.
- Ved spill ferdigstillelse post tilbake følgende: game starttid, hvert trekk tatt og når, og klientsiden resultater.
- På serveren å kjøre spillet med de gitte data, tilregnelighet sjekker starttid og flytte ganger, og deretter bekrefte at resultatene kampen.
- For å dempe denial of service, vil selve spillet bli forskjøvet til å ha en seier ved å slå X tilstand.
- For å motvirke serveren blir brukt som et orakel av former, vil en bruker legger tilbake et ugyldig spillet bli utestengt for en konstant tid X (X er i størrelsesorden minutter).
Denne konstruksjonen krever tre Facebook samtale per spill spilt: en til å lagre tilfeldig frø før kampen spilles, en for å hente det etter kampen er ferdig, og en for å oppdatere spillerens score hvis spillet er gyldig.
Det jeg prøver å bevis systemet mot er rett opp stillingen spoofing ( http: // ... myscore = 999999999 , eller lignende). Jeg vil også gjerne redusere se fremover angrep, der brukeren kan fortelle hva brikkene kommer til styret neste. Denial of service angrep på hosting server (tilsiktet eller annet) bør også unngås.
Selve spørsmålet, kan noen se en feil i denne design? Tilsvarende er det et enklere design som oppfyller mine kriterier?
Merk: Jeg er klar over hvor unødvendig dette sannsynligvis er, men det er et interessant spørsmål ikke desto mindre.
Jeg kommer til å prøve og kaste noen tall opp her for å gi enda illustrere mitt resonnement, disse er ganske tøft, men jeg håper nyttig.
Forutsatt en 10x10 spillbrettet, det er ~ 200 potensielle trekk (bytte to tilstøtende brikker) hvorav de fleste er ugyldig. La oss si at det er i gjennomsnitt 5 gyldige trekk per turn. Hvis vi begrense spillernes handlinger til rammen på 50 til 30 000 millisekunder, er det 149,750 potensielle nye hashes følger den tweaking algoritmen ikke kaste biter; Jeg føler meg trygg på å si at det er minst 10.000 potensielle nye hashes som må beregnes av en angriper å anta en kryptografisk sikre hash brukes. Hvis du kaster en min-max algoritme på dette, beslutning tre eksploderer svært raskt. Kast en spilløkt utløp på dette, sier 30 minutter, og jeg tror angrepet fordi tilsvarende i kompleksitet til å skrive en liten bot program til å spille for deg som ikke med rimelighet kan forsvares mot.
