Dies ist mehr eine System-Design Frage / Herausforderung, als eine Codierung Frage.
Grundsätzlich denke ich an das Werfen einer zusammen Bejeweled -esque Spiel auf Facebook mit nur HTML, CSS und Javascript. Dies ist vor allem aus dem Wunsch , all die kleinen Einsprüche von FBJS über ein nicht-triviales Projekt zu erfahren.
So, hier ist der Deal. Wenn für Facebook zu entwickeln, sind tatsächliche API-Aufrufe sehr teuer; gibt es nicht nur eine zusätzliche POST zu den Facebook-Servern gibt Grenze auch die api Anruf ist und zur Sorge Drosselung. Auf den Punkt gebracht, die weniger Anrufe zu Facebook, desto besser. Kombinieren Sie dies mit dem Timing Anliegen auch dieses einfachen Puzzle-Spiels, und es gibt gute Gründe für die aggressiv die Anzahl der Rückrufe im Allgemeinen zu minimieren.
Kein Sicherheitsexperte sein, hier ist der Entwurf, den ich habe kommen mit:
- Einbetten eines zufälligen Samen im Spiel Seite.
- Verwenden Sie, dass Saatgut, das Spielbrett zu erstellen (sowie zusätzliche Stücke je nach Bedarf).
- Zwicken die Samen (xor, verketten und Hash, so ähnlich) nach jedem Spieler bewegen, basierend auf der Zeit seit dem letzten Zuge. Edit: Ich sollte wohl auch die tatsächliche Bewegung genommen in den Samen mutiert.
- Nach dem Spiel Abschluss post die folgenden zurück: Spielzeit starten, jeder Zug genommen und wenn, und die Client-Seite Ergebnisse.
- Auf dem Server, das Spiel mit den angegebenen Daten erneut ausführen, vernunft die Startzeit und bewegt mal überprüft, und bestätigen Sie dann, dass die Ergebnisse übereinstimmen.
- Um Denial-of-Service zu mildern, wird das Spiel selbst einen Gewinn von wiederum X Zustand zu haben, wird gezwickt.
- Zu entmutigen der Server als „Orakel“ verwendet wird, der Art, ein Benutzer Posting ein ungültiges Spiel zurück wird für eine Konstante Zeit X verboten werden (X in der Größenordnung von Minuten sein).
Diese Konstruktion erfordert drei Facebook Anruf pro Spiel gespielt: man die zufälligen Samen zu speichern, bevor das Spiel gespielt wird, man es holen, nachdem das Spiel beendet ist, und man das Ergebnis des Spielers zu aktualisieren, wenn das Spiel gültig ist.
Was ich versuche , das System zu Beweis gegen ist gerade nach oben Punktzahl Spoofing ( http: // ... myScore = 999999999 , oder ähnlichem). Ich möchte auch „look ahead“ Angriffe abzuschwächen, wobei der Benutzer sagen , welche Teile neben dem Spielbrett kommen. Denial - of - Service - Angriffe auf dem Hosting - Server (absichtlich oder nicht) sollte ebenfalls vermieden werden.
Die eigentliche Frage, jeder kann einen Fehler in diesem Entwurf sehen? Gleichwertig, gibt es eine einfachere Konstruktion, die meine Kriterien erfüllt?
Hinweis: Ich bin mir bewusst, wie unnötig es wahrscheinlich ist, aber es ist eine interessante Frage, nicht weniger.
Ich werde ein paar Zahlen, um zu versuchen und zu werfen hier auf meine Argumentation futher veranschaulichen, sind diese ziemlich rau, aber ich hoffe, hilfreich.
Unter der Annahme einer 10x10 Spielbrett gibt es ~ 200 Potential bewegt (Vertauschen zweier benachbarter Stücke) von denen die meisten sind ungültig. Lassen Sie uns sagen, dass es im Durchschnitt 5 gültigen Züge pro „drehen“. Wenn wir Aktionen der Spieler auf den Rahmen von 50 bis 30.000 Millisekunden zu beschränken, gibt es 149.750 potentiellen neuen Hashes den „Zwicken“ Algorithmus zur Verfügung gestellt keine Bits verwerfen; Ich bin zuversichtlich, in sagen, es gibt mindestens 10.000 potenziellen neuen Hashes, die von einem Angreifer berechnet werden müssen einen kryptografisch sicheren Hash unter der Annahme verwendet wird. Wenn Sie einen Min-Max-Algorithmus auf diese werfen, den Entscheidungsbaum explodiert sehr schnell. Werfen Sie eine Spielsitzung Ablauf in diesem, sagen 30 Minuten, und ich glaube, den Angriff, weil gleichwertig in ihrer Komplexität zu ein wenig Bot-Programm zu schreiben für Sie zu spielen, die gegen verteidigt werden vernünftigerweise nicht.
