Ceci est plus une question de conception du système / défi, qu'une question de codage.
En fait, je pense à jeter ensemble un Bejeweled jeu esque sur Facebook en utilisant seulement HTML, CSS et javascript. Ceci est la plupart du temps d'un désir d'apprendre toutes les petites mises en garde de FBJS par un projet non trivial.
Alors, voici l'affaire. Lors du développement de Facebook, les appels API réels sont très chers; non seulement est-il un poste supplémentaire aux serveurs de Facebook, il y a aussi la limite d'appel api et étranglant à se soucier. En un mot, le nombre d'appels à Facebook le mieux. Combinez cela avec les préoccupations de synchronisation de même ce jeu de puzzle simple, et il y a de bonnes raisons de minimiser agressivement le nombre de callbacks en général.
Ne pas être un expert en sécurité, voici la conception que je suis venu avec:
- Intégrer une graine aléatoire dans la page du jeu.
- Utilisez cette graine pour créer le plateau de jeu (ainsi que des pièces supplémentaires au besoin).
- Tweak la graine (XOR, concaténer et hachage, quelque chose comme ça) après chaque mouvement des joueurs, en fonction du temps depuis la dernière décision. Edit: Je dois inclure probablement aussi le mouvement réel pris dans la graine muter.
- À la fin du jeu republier les éléments suivants: début de jeu le temps, chaque mouvement pris et quand, et les résultats du côté client.
- Sur le serveur, relancez le jeu avec les données fournies, le bon sens vérifier l'heure de début et de déplacer les temps, puis confirmer que les résultats correspondent.
- Pour atténuer le déni de service, le jeu lui-même sera modifié pour avoir une victoire par condition tour X.
- Pour décourager le serveur utilisé comme un « oracle » de toutes sortes, un utilisateur affichant de nouveau un jeu non valide sera interdit pendant un certain temps constant X (X étant de l'ordre de minutes).
Cette conception nécessite trois appels Facebook par match joué: un pour stocker la graine aléatoire avant que le jeu est joué, on vient le chercher pour après le match est terminé, et un pour mettre à jour le score du joueur si le jeu est valide.
Ce que je suis en train de preuve le système contre l' usurpation d' identité est en hausse de score droit ( http: // ... myScore = 999999999 , ou similaire). Je voudrais aussi atténuer « regarder vers l' avenir » les attaques, dans lequel l'utilisateur peut dire ce que les pièces arrivent à la carte suivante. Des attaques par déni de service sur le serveur d'hébergement (intentionnel ou non) devrait également être évitée.
La question réelle, peut-on voir une faille dans cette conception? De manière équivalente, est-il une conception plus simple qui répond à mes critères?
Note: Je sais comment cela est probablement inutile, mais ce une question intéressante pas moins.
Je vais essayer de jeter quelques chiffres ici pour futher illustrer mon raisonnement, ceux-ci sont assez rude, mais j'espère utile.
En supposant un plateau de jeu de 10x10, il y a ~ 200 mouvements potentiels (swapping deux pièces adjacentes) dont la plupart ne sont pas valides. Disons qu'il ya en moyenne 5 mouvements valides par « tourner ». Si nous limitons les actions des joueurs au cadre de 50 à 30 000 millisecondes, il y a 149,750 nouveaux hash potentiels fournis l'algorithme « peaufinage » ne pas jeter bits; Je suis confiant en dire, il y a au moins 10.000 nouveaux hash potentiels qui doivent être calculés par un attaquant en supposant utilise un hachage cryptographique sécurisé. Si vous jetez un algorithme min-max à cela, votre arbre de décision explose très rapidement. Jeter une expiration de la session de jeu à, disons que 30 minutes, et je crois que l'attaque en raison de la complexité équivalente à écrire un petit programme de bot à jouer pour vous qui ne peut être raisonnablement défendue contre.
