Dit is meer een systeemontwerp vraag / uitdaging, dan een codering vraag.
In principe ben ik aan elkaar gooien van een Bejeweled esque game op Facebook met behulp van alleen HTML, CSS en Javascript. Dit is veelal uit een verlangen om alle kleine valkuilen van FBJS leren via een niet-triviaal project.
Dus hier is de deal. Bij het ontwikkelen voor Facebook, de werkelijke API calls zijn erg duur; niet alleen is er een extra post naar de servers van Facebook, is er ook de api call limiet en smoren aan de hand. In een notendop, hoe minder oproepen naar Facebook, hoe beter. Combineer dit met de timing zorgen van zelfs deze eenvoudige puzzel spel, en er is een goede reden om het aantal callbacks in het algemeen agressief te minimaliseren.
Niet zijnde een security expert, hier is het ontwerp dat ik ben gekomen met:
- Insluiten een random seed in het spel pagina.
- Gebruik dat zaad het speelbord te creëren (evenals extra stukken als dat nodig is).
- Tweak het zaad (xor, aaneenschakelen en hash, iets dergelijks) na elke speler zet, gebaseerd op de tijd sinds de laatste zet. Edit: Ik moet waarschijnlijk ook de feitelijke verhuizing genomen in het muteren van het zaad op te nemen.
- Bij het spel voltooiing postrug de volgende: spel starttijd, elke beweging genomen en wanneer, en de client resultaten.
- Op de server, re-run het spel met de gegeven data, geestelijke gezondheid controleren van de starttijd en bewegen tijden, en bevestig dat de resultaten match.
- Om denial of service te beperken, zal het spel zelf worden geknepen om een win-by-turn X conditie.
- Om te ontmoedigen de server die wordt gebruikt als een orakel van soorten, zal een gebruiker het plaatsen terug een ongeldige spel worden verboden enige constante tijd X (waarbij X in de orde van minuten).
Dit ontwerp vereist drie Facebook oproep per spel gespeeld: een naar de random seed op te slaan voordat het spel wordt gespeeld, een om het te halen na de wedstrijd is afgelopen, en een om de score van de speler bij te werken als het spel is geldig.
Wat ik probeer te bewijzen het systeem tegen recht omhoog score spoofing ( http: // ... myscore = 999999999 , of iets dergelijks). Ik zou ook graag af te zwakken vooruit kijken aanvallen, waarbij de gebruiker kan vertellen wat stukken komen aan de raad volgende. Denial of Service-aanvallen op de hosting server (opzettelijk of anderszins) moet ook worden voorkomen.
De werkelijke vraag, kan iedereen zien een fout in dit ontwerp? Equivalently, is er een eenvoudiger ontwerp dat voldoet aan mijn criteria?
Opmerking: Ik ben me ervan bewust hoe onnodige dit waarschijnlijk is, maar het is een interessante vraag niettemin.
Ik ga proberen en gooien een aantal nummers hier om futher illustreren mijn redenering, deze zijn vrij ruw, maar ik hoop dat nuttig.
Uitgaande van een 10x10 bord, zijn er ~ 200 mogelijke moves (het omwisselen van twee aangrenzende stukken) waarvan de meeste zijn ongeldig. Laten we zeggen dat er gemiddeld 5 geldig moves per turn. Als we beperken speler acties aan het frame van 50 tot 30.000 milliseconden, zijn er 149.750 potentiële nieuwe hashes op voorwaarde dat de tweaken algoritme niet stukjes ontdoen; Ik voel vertrouwen in zeggen er ten minste 10.000 potentiële hashes die worden berekend door een aanvaller uitgaande van een cryptografisch beveiligde hash wordt gebruikt. Als je gooit een min-max-algoritme in deze, uw beslissing boom explodeert zeer snel. Gooi een spelsessie expiratie op dit, zeg 30 minuten, en ik denk dat de aanval, omdat equivalent in de complexiteit van het schrijven van een beetje bot programma om te spelen voor u, die redelijkerwijs niet kan worden verdedigd tegen.
