22-07-2019, 07:12 PM
Bon, finalement, c'est rigolo à implémenter, mais totalement inutile et impossible à présenter potablement aux utilisateurs 
Dans le proto que j'ai fait et jeté direct, j'avais stocké la clef publique côté serveur (déjà, le client doit l'uploader, donc c'est pas top pour l'ux), et à la connexion, le client va chercher le fichier de sa clef privée (moisi également car non-enregistré par le navigateur), puis la CryptoAPI JS lit la clef (bien bien chiant à faire!), signe le pseudo du joueur (donc, le client doit aussi entrer son pseudo...), envoie le pseudo & signature au serveur, qui vérifie que le pseudo existe en DB pour récupérer l'ID du joueur (je n'économise même pas l'appel à la DB...), puis le serveur va chercher la clef publique stockée, et il vérifie que la signature du pseudo est valide pour cette clef publique (c'est le seul truc facile: openssl_verify en PHP)
Je laisse donc tomber
Les alternatives que je me suis amusé à explorer au passage:
- Authentification via www-authenticate: je ne suis pas allé très loin, puisqu'au final, cela sert juste à faire une autre interface pour demander le login & password du joueur, et que ces infos traineront dans les headers inutilement (je pensais pouvoir me passer de la session grâce à ça, mais cela impliquerait que ma session ne stocke que le login du joueur; or déjà, elle stocke l'id et non le pseudo et je ne m'interdis pas d'y stocker 2-3 autres infos si besoin)
- Authentification via certificat: j'aurai pû/dû aller plus loin car c'est intéressant comme concept, mais je n'ai pas réussi à charger mon certificat dans le navigateur et je ne suis même pas sûr de pouvoir le récupérer côté PHP pour ensuite le valider par le serveur... C'est probablement négocié plus bas dans la stack réseau, donc tant pis...
Bon, ben ce fut une belle idée inutile
Dans le proto que j'ai fait et jeté direct, j'avais stocké la clef publique côté serveur (déjà, le client doit l'uploader, donc c'est pas top pour l'ux), et à la connexion, le client va chercher le fichier de sa clef privée (moisi également car non-enregistré par le navigateur), puis la CryptoAPI JS lit la clef (bien bien chiant à faire!), signe le pseudo du joueur (donc, le client doit aussi entrer son pseudo...), envoie le pseudo & signature au serveur, qui vérifie que le pseudo existe en DB pour récupérer l'ID du joueur (je n'économise même pas l'appel à la DB...), puis le serveur va chercher la clef publique stockée, et il vérifie que la signature du pseudo est valide pour cette clef publique (c'est le seul truc facile: openssl_verify en PHP)
Je laisse donc tomber
Les alternatives que je me suis amusé à explorer au passage:
- Authentification via www-authenticate: je ne suis pas allé très loin, puisqu'au final, cela sert juste à faire une autre interface pour demander le login & password du joueur, et que ces infos traineront dans les headers inutilement (je pensais pouvoir me passer de la session grâce à ça, mais cela impliquerait que ma session ne stocke que le login du joueur; or déjà, elle stocke l'id et non le pseudo et je ne m'interdis pas d'y stocker 2-3 autres infos si besoin)
- Authentification via certificat: j'aurai pû/dû aller plus loin car c'est intéressant comme concept, mais je n'ai pas réussi à charger mon certificat dans le navigateur et je ne suis même pas sûr de pouvoir le récupérer côté PHP pour ensuite le valider par le serveur... C'est probablement négocié plus bas dans la stack réseau, donc tant pis...
Bon, ben ce fut une belle idée inutile