Panel klienta WaveHost

WaveHost est un hébergeur qui avait besoin d'un seul endroit pour ses clients : vous commandez un serveur, vous payez, vous parrainez, le tout depuis le même panneau. Cette partie seule est un travail d'artisan que nous avions déjà fait. Le vrai défi était à côté : chez l'hébergeur tournait déjà un panneau de jeux séparé avec ses propres comptes, et ces deux mondes devaient être reliés pour que le client ressente un seul système, et non deux.

Le plus simple serait de faire connecter les gens deux fois et de relier un compte à la main par e-mail. Mais c'est un chemin direct vers les erreurs, et avec la liaison de comptes une erreur a un prix concret : rattachez à quelqu'un un compte qui n'est pas le sien et vous avez un problème qu'un simple désolé ne peut pas défaire. Nous voulions une liaison à laquelle on peut faire confiance. Cette étude de cas parle surtout de cette liaison.

Le fondement du panneau, c'est le service auquel le client revient chaque jour. La commande et la gestion des serveurs couvrent aussi bien les VPS que les machines dédiées, avec leur état et leur configuration visibles dans une seule vue. Le client ne saute pas entre les outils pour vérifier ce qu'il a et dans quel état c'est.

Autour de cela vit le reste du service. Le portefeuille et les factures sont côte à côte, de sorte que le solde, les paiements et les documents forment un tout, et non trois onglets séparés qu'il faut concilier soi-même. Le programme de parrainage ajoute un lien de parrainage et un flux de commission clair, branché sur le même portefeuille. L'ensemble repose sur une stack moderne avec une authentification sécurisée, parce que c'est un panneau où se trouvent de l'argent et des accès serveurs.

Le cœur du projet, c'est la liaison du panneau client avec le panneau de jeux existant. Du côté du client, le problème est à la fois banal et agaçant : deux comptes, deux connexions, deux mondes qui ne l'intéressent pas, parce qu'il veut simplement tout gérer au même endroit. Du côté de l'ingénierie, c'est justement la partie où il est facile de faire quelque chose de dangereux.

La solution naïve est la suivante : que le client donne son identifiant du panneau de jeux et nous le rattachons. Le problème est que, de cette façon, n'importe qui pourrait donner l'identifiant de quelqu'un d'autre et se rattacher à un compte qui n'est pas le sien. La liaison manuelle par e-mail est lente et tout aussi trouée. Il nous fallait un moyen par lequel un système prouve à l'autre l'identité du client, sans faire confiance à quoi que ce soit qui passe par le navigateur.

La solution est un handshake basé sur HMAC. Quand le client clique sur "relier le compte" dans le panneau WaveHost, le panneau génère un lien portant l'identifiant de l'utilisateur, un horodatage et une signature calculée avec un secret que seuls les deux panneaux connaissent. Le panneau de jeux reçoit ce lien, recalcule la signature avec son propre secret et compare. Si elle correspond, il sait que la requête est réellement venue du panneau WaveHost et non de quelqu'un qui a falsifié l'URL.

Ce qui compte, c'est ce que le navigateur ne voit jamais. Le secret ne quitte pas les serveurs, donc même quelqu'un qui observe ou intercepte le lien ne peut pas calculer une signature valide pour un autre identifiant. L'horodatage ferme la seconde faille : le lien est de courte durée, et le panneau de jeux rejette simplement un token expiré, de sorte qu'un lien capté ne peut pas être utilisé plus tard.

Il vaut la peine de décomposer cela en scénarios, car c'est seulement alors qu'on voit que le confort ne coûte vraiment pas de sécurité. Quelqu'un remplace l'identifiant dans le lien par un autre, pour se rattacher à un compte qui n'est pas le sien. La signature cesse de correspondre, parce qu'elle a été calculée pour un identifiant différent, et une nouvelle ne peut pas être générée sans le secret. Le panneau de jeux rejette la requête.

Deuxième scénario : quelqu'un intercepte le lien valide d'un client et essaie de l'utiliser. Ici l'horodatage sauve la mise. Le lien vit peu de temps, donc intercepté après coup il est déjà sans valeur, et le panneau de jeux traite un token expiré exactement comme un falsifié. Dans les deux cas, la frontière est vérifiée du côté serveur, à l'entrée, et non dans l'interface, qui peut toujours être contournée.

Le client mène tout le service depuis un seul endroit. Il commande des serveurs, gère des VPS et des machines dédiées, paie, parraine et surveille son portefeuille sans sauter entre les outils. La liaison au panneau de jeux fonctionne en un clic au lieu d'un échange d'e-mails, de sorte que les deux systèmes de l'hébergeur donnent au client l'impression d'un seul.

En dessous, ce confort n'est pas payé au prix de la sécurité, parce que le handshake est de courte durée et signé et que le secret n'atteint jamais le navigateur. Un lien falsifié ou intercepté ne rattachera pas un mauvais compte, parce que le serveur garde la frontière à l'entrée, et non l'interface. C'est exactement le genre de solution dont il était question dans le projet : simple pour le client, dur là où cela doit être dur.