JeuWeb - Crée ton jeu par navigateur

Salutations,

comme de plus en plus de sites et de jeux étalent du JS à tout va (le plus "beau" étant Polymer, qui n'est jamais que du XML interprété par du JS spécifique à chaque site web), je suppose qu'il existe des méthodes permettant de remonter les bugs de ces JS aux développeurs des sites.

Mais les connaissez-vous? Je ne trouve pas vraiment de solution qui soit capable d'allier:
• Stateless server (je ne veux pas enregistrer des quotas & des tokens dans la BDD pour ces reports de bug)
• Sécurisé (je ne veux pas qu'un client ait juste à renvoyer en boucle les requêtes pour signaler des faux bugs)
• Gratuit (open source, ou simplement une méthodologie que j'ai à implémenter moi-même)
• Interfaçable (je souhaite remonter ces bugs dans Mantis, donc, j'aimerai trouver une approche qui s'interface bien avec SOAP)
• "Sans login" (en fait, j'aimerai être capable de logger les erreurs des joueurs loggés qui jouent, mais j'aimerai aussi logger les erreurs des visiteurs ou des joueurs pas encore loggés: j'ai peur de perdre masse de logs si je ne reporte que les erreurs des gens connectés avec un compte de jeu)


Pour ce qui est de chopper l'erreur et ses informations dans le JS, ça va. J'ai déjà mon petit event listener "error" sur window, qui remonte actuellement un message à l'écran de l'utilisateur (j'aimerai le supprimer à terme: beaucoup d'utilisateurs s'en moquent, mais c'est pratique pour l'environnement de dev) et j'aimerai donc lui faire remonter l'info au serveur, mais je n'ai pas trouvé d'approche sécurisée pour ça. Des idées/suggestions?

---

En fait, je m'aperçois que cela pourrait être étendu à: Comment les clients lourds (logiciels type GIMP, Firefox etc) font pour remonter automatiquement leurs bugs, sans que des "petits malins" ne remontent de faux bugs en craftant les requêtes?

Bah regarde comment font les clients web : en gros tu peux pas bloquer donc tu limites à x requettes par seconde et tu filtres les relous qui en envoient tous les jours.

Oui mais là, tu limites uniquement au nombre de logs, pas aux logs craftés qui ne mènent nulle part. ok, je ne sais pas si quelqu'un s'amusera à crafter des logs et à perdre du temps pour le plaisir de me faire perdre du temps, mais ce sont ces logs-là que j'aimerai éviter: des logs légitimes qui spamment, je m'en fous un peu de les bloquer (c'est peut-être pas une bonne idée d'ailleurs), mais des "faux-logs", ça, j'aimerai bannir.

Mais je ne vois pas comment ce serait faisable, de part l'archi client/server elle-même... D'où ma question: comment font les clients lourds (ou clients web) pour s'assurer que les logs sont bien "légitimes" et correspondent bien à du bug survenir dans le client et non pas à du craft (si jamais ils arrivent à faire cette discrimination).

Il y a peut-être une histoire de chiffrement : l'app chiffre le contenu avec une clé, et le serveur déchiffre avec. Et à moins que les "fakers" ne trouvent la clé, leurs fakes sont rejetés car non chiffrés ou chiffrés avec la mauvaise clé.

Et sinon on peut rejeter selon un indice de confiance : quand un même bug et reporté par plusieurs clients, son indice est fort, sinon il est faible et on l'ignore.

Sinon faut coder en Elm pour éviter les erreurs à l'exécution. :p

Qu'est-ce qui différencie un report crafté d'un légitime ? Comment l'appli peut-elle deviner qu'il y a vraiment eu un bug ? Si tu en est à faire de faux reports tu va facilement throw un truc manuellement dans la console.

Citation :Qu'est-ce qui différencie un report crafté d'un légitime?

C'est la question: j'aimerai savoir si un discriminant vous vient à l'esprit, car je n'en trouvais pas.
Or, si on m'avait demandé il y a quelques temps "comment stocker des données chez un client sans qu'il ne puisse les altérer", je n'aurai probablement pas trouvé le système de "le serveur rajoute un secret aux données à stocker chez le client, et hash le tout pour créer une signature 'certifiant' autant que possible que les données n'ont pas été altérées".
Donc, je me suis dit que vous auriez peut-être également connaissance d'une astuce pour la remontée de bugs d'une appli cliente.