WebSocket, comment identifiez-vous vos joueurs ?

[Sephi-Chan]

Coucou !

Dans le cadre de mon projet Seelies, j'ai décidé d'opter pour WebSocket dans le cadre des communications du serveur vers le client.

J'aimerais maintenir un hash qui associe un joueur (par son identifiant unique, notamment) à sa connexion persistante. Seulement, on a peu d'information sur qui est le joueur quand la connexion est établie.

Quelle solution avez-vous retenu pour cela ? Je pensais opter pour lire le cookie HTTP de la requête de connexion.

[Maks]

Si tu parles du moment T de la connexion, moi je lis le cookie (crypté) de session lors de la poignée de main pour savoir qui vient de se connecter oui.

[Ditret]

je ne sais pas si ça va t'aider ( ou si certain on des solutions meilleures =3 )
Pour mon jeu j'ai utilisé une méthode que je trouve un peu bizarre mais qui marche ( pour le moment ^^ )( serveur node.js )

1 - j'établie la connexion entre le client/serveur et cette session possède une variable bool a false.
2- le client envoi son login/password sur une socket 'login', si l'id est pas déja connecter et que le mdp correspond ( requête SQL ), je passe ma variable bool a true
3- A chaque fois que le client envoie un message autre que 'login', je test la variable bool pour voir si il est log ou pas.

le gros inconvénient de cette méthode et que si 50 personnes ce connectent et ce log pas, ça pourrait ralentir le serveur ...

[Argorate]

Surtout, n'importe qui peux bidouillé ta variable JS est la passé a true non? je vois pas bien l’intérêt?

Sinon le mieux serait comme dit maks d'associer à chaque joueur une key. De la meme manière que le token anti CSRF qu'on met donc dans une balise HTML (par exemple) lors du chargement de la page (attribué par le serveur donc) et cette clé est envoyé pour l'authentification la première fois (connexion).
Comme ça on sait a qui on a a faire, et si on veux on peux même faire changer le token a chaque connexion comme ça même un inconscient ou une mauvaise manip qui donne son token restera protégé.

non?

[niahoo]

j'utilise websocket avec un fallback en long-polling et comme Maks je lis son persistence_token qu'il fournit via ses cookies. Par contre il n'est pas crypté. Comment tu le cryptes ? https & ssl ?

[yceos]

Bonjour,

J'ai pas encore beaucoup "joue" avec les websockets, mais du peu que j'ai vu sur Node.JS si tu ouvre la socket apres l'authent et donne a l'objet une info specifique (genre un ID ou un login) ca devrait etre suffisant. (modulo eventuellement du https). Normalement la websocket c'est justement d'ouvrir et maintenir un canal ouvert entre le serveur et un client, le client d'a cote aura une socket differente.

J'ai seulement explore en surface mais dans mes tests ca marchait sans soucis comme ca. Mon test en question etait un petit chat basique, dans l'idee de l'integrer a Spacelife j'authentifiais le joueur a l'entree sur le jeu et au passage ouvrais une socket avec Socket.IO). J'avais trouve ca "magique" en fait, ca marche sans se forcer (on reconnait bien la le cote faineant de l'informaticien !).

[Ditret]

Argorate > cette variable se trouve uniquement du coté serveur, donc pas modifiable par le client. le client peut juste faire un socket.send('login','mdp':XXX,'id':XXXX); pour pouvoir passer ça variable login a true.

[Maks]

j'utilise websocket avec un fallback en long-polling et comme Maks je lis son persistence_token qu'il fournit via ses cookies. Par contre il n'est pas crypté. Comment tu le cryptes ? https & ssl ?

Moi je fais rien de special, c'est express qui crypte les cookies avec une clé cookie_secret. En cas de connexion permanente j'ai aussi un jeton qui vient de rails donc non crypté sinon un id stocké a une connexion reussie via express (cookie httpOnly).

Sinon oui je passe toujours par SSL, donc https:// et wss:// pour les url

[Argorate]

Ok, j'avais mal comprit Ditret.

Sinon passé par wss tout le temps ça te ralenti ton temps de réponse car allonge en taille tous les échanges non? C'est un peu dommage puisque c'est le point faible/sensible, le temps de réponse.

[Maks]

Je ne sais pas tu as plus d'infos ? Je passe les websockets en securisé via proxy nginx, ca ne fonctionne pas sinon. Je ne sais pas si il y a moyen de faire mieux, si c'est plus rapide sous HAProxy par exemple. C'est frustrant de ne pas avoir les connaissances pour deployer au mieux ce genre d'application