Opérations en Hors ligne

[Sephi-Chan]

Bon, j'ai fais une petite check liste pour faire de cet outil un service en ligne.

Pour commencer, il faut ajouter un système d'authentification. Je compte utiliser 3 clés : une API key, une secret key et une publish key. Toutes les queues auront l'API key comme scope, histoire de simplifier extrêmement les conflits de nommage (et de s'épargner plein de tests). La publish key sera envoyées (dans un header) dans les notifications de fin de construction pour que le client puis s'assurer que c'est bien le service de notification qui l'envoie. Enfin, la secret key devra être envoyée par le client (dans un header, là aussi) quand il enverra des commandes au service.

Ça devrait pouvoir être sympa !

[nicodd]

Si les clés publique et privée circulent telles quelles, quelle est la plus value en terme de sécurité ?

[Sephi-Chan]

Il n'y a pas de couple clé publique/clé privée. Ici, les clés sont uniquement échangées entre le serveur qui héberge le jeu et le service.
Du site vers le service, c'est la secret key qui est envoyée : bonjour service, je suis bien le jeu que je prétends être car je connais la clé qu'on partage.
Du service vers le site, c'est la publish key : bonjour site, je notifie que l'opération est terminée et je te montre que je suis bien le service car je connais la clé qu'on partage.

Ça me semble honnête même si je suis à l'écoute d'un potentiel meilleur système.

[Myrina]

Pourquoi ne pas faire:

Du site vers le service, c'est la secret key qui est envoyée : bonjour service, je suis bien le jeu que je prétends être car je connais la clé qu'on partage ainsi qu'un identifiant unique généré par le site.
Du service vers le site, c'est un hash de l'identifiant unique avec la publish key : bonjour site, je notifie que l'opération est terminée et je te montre que je suis bien le service car le hash que je te renvoie correspond au hash que tu ferais avec l'identifiant unique que tu avais créé avec la publish key que l'on partage.

Il faut, au préalable, convenir d'un algorithme de hashage commun.

[Sephi-Chan]

Quel est l'interet de cette approche ?

[Myrina]

- avoir un moyen pour le site de corréler la réponse avec une de ses demandes
- garantir au site que c'est bien le service qui répond et non un usurpateur

[atra27]

en faisant un md5 de verrif des données concaténé avec la clé, ainsi la clée n'est jamais envoyée seule et en clair! de plus on ajoute un moyen de vérifier a la fois l'intégrité des données recues en clair et authentifier le service!

Simple non?

[niahoo]

oui mais sans cryptage ça revient au même .. envoyer une clé ou un hash de la clé plus quelque chose d'autre, si quelqu'un intercepte ces données il peut toujours en envoyer d'autres

sinon des clés publique/privée genre SSH mais j'ai toujours pas pigé le principe de base.

[Tyc]

Bonjour,

J'ai lu attentivement votre discussion et je me posais une question.

J'ai découvert aujourd'hui Node.js et ai regardé quelques tutoriaux à propos. Je n'ai pas encore testé.

N'est-il pas possible de réaliser un système de queue (pour la construction de bâtiments par exemple) uniquement avec Node.js?

Je voyais la chose comme suit :

- Le navigateur effectue une requête en ajax par exemple vers l'url et le port écoutés par Node et exécute la fonction qui va bien.

- Cette fonction reçoit divers paramètres dont le temps nécessaire à la construction.

- A la fin du timer, Node se charge d'appeler un script php qui va mettre à jour la base de données.

- Dans le navigateur, dans le cas où l'utilisateur ne l'a pas fermé, un éventuel compte à rebours en js arrive au terme, effectue une requête Ajax et vérifie que le bâtiment a bien été construit. Si oui l'affichage change.


Voilà, ce sont sans doute des interrogations de débutant car je le suis en matière de jeux. C'est une approche complètement différente de la programmation que je fais au quotidien ( je suis développeur de site web en agence ) aussi j'espère que vous prendrez le temps d'éclairer ma lanterne !

Merci d'avance

[Sephi-Chan]

J'avais pensé à adopter l'approche de Facebook, à savoir un paramètre qui est juste une chaîne encodée (que le site et/ou le service est capable de décoder), mais tout ça me semble bien compliqué pour si peu. Les clés dont je parle sont échangées entre 2 serveurs : ça ne se spoof pas aussi facilement qu'un ordinateur ! Et HTTPS arrangera le reste.

@ Tyc (bienvenue, au passage) : ton approche est globalement celle que j'ai choisie, à quelques différences près :

• C'est le serveur du jeu qui envoie les ordres de construction au service, pas le navigateur du client : ceci évite que la personne puisse ajouter ce qu'il veut comme il veut, et même que d'autres personnes puissent ajouter des choses au nom d'autres. À moins de développer le jeu entièrement avec NodeJS, ici, le service n'a pas conscience des joueurs : il ne voit que des queues et ce qu'elles contiennent.
  
• Utiliser un outil de stockage (ici, j'utilise Redis car c'est terriblement performant puisque ça ne travaille qu'en RAM) permet de stocker l'état de la queue : ton système ne peut pas gérer une queue au sens propre : avec des éléments qui s'enchaînent les uns après les autres.
  
• Quand un compteur arrive à terme, NodeJS envoie une requête HTTP au serveur de jeu : le jeu fait alors ce qu'il a à faire avec ça : libre à lui de le retransmettre au navigateur client (via du push, par exemple).
  

Voilà, voilà, j'espère que ma réponse t'aura éclairé sur les intérêts d'un service qui en sait peu et qui est capable de stocker.