Discussion :

[gilloddon]

Bonjour,

Je suis en train de réaliser un petit serveur avec Node.js, assez simple : il s'agit quasi uniquement de webservices (connexion, déconnexion, upload/download d'un fichier, changement de login en résumé). Etant donné que tous les webservices sont liés au compte d'un utilisateur, j'aimerais mettre en place un petit système de token.

J'ai déjà réalisé des applications mobiles qui utilisent un tel système pour retenir le token et le renvoyer lors de l'utilisation des webservices pour identifier l'utilisateur (au lieu d'envoeyr à chaque fois les identifiants, on peut garder pendant une durée limité le token)... mais je n'ai jamais réalisé ni même vu comment fonctionner réellement un tel système.

En réfléchissant rapidement, je me suis dis que je pourrais gérer ça en base de données, avec un table Token qui posséderait un id donné aux applis plus une date d'expiration et qui serait lié à la table Utilisateur. A première vue, comme ça, je dirais que ça fonctionne mais ce n'est probablement pas l'idéal.

J'ai aussi l'impression de ré-inventer la roue, donc dans un premier temps, je souhaiterais savoir s'il n'y a pas un système efficace déjà présent dans node.js ?
De même, est-ce qu'il existe un "modèle de conception", une "bonne manière" pour mettre en place un système de token fiable ?
Sinon, que me conseillez-vous pour créer un petit système de token ?

Merci d'avance !

[Invité]

Salut,

Si j'ai bien compris, ce que tu cherches à faire est à l'image des systèmes de sessions utilisés pour le web :

• L'utilisateur s'authentifie
• Une session est créee (en base / en mémoire / dans un fichier) avec un ID (token / sessionId) qui l'identifie
• Un cookie est posé avec ce token
• Le cookie est renvoyé dans chaque nouvelle requête, ce qui permet de raccrocher la requête à l'utilisateur

Pour la mise en place d'un système de ce type, tout dépend de ta conception. Comment l'utilisateur accède t-il à tes services ? via une page web, un client lourd (en TCP/HTTP ?), par l'intermédiaire d'un autre serveur ?

[gilloddon]

Oui c'est ça, tu as globalement bien résumé ce que je cherche à faire.
Petite question d'ailleurs, par rapport à ce que tu as dis : en plus du token/sessionId, on utilise aussi les cookies pour faire le lien ?
J'ai jamais trop regardé de près ce genre de système, surtout dans le web (comme dit plus haut, j'en ai utilisé un peu sur des applications mobiles où je recevait un token [juste un string] à la connexion, et que je renvoyait ensuite en paramètres aux services nécessitant d'être connecté).


Pour ce qui est des détails, c'est un client lourd réalisé en C++ et installé sur la machine de l'utilisateur.
Cette application communiquera avec le serveur Node.js à travers des webservices : en gros, des appels HTTP GET/POST et un retour en JSON.

[Invité]

Les cookie sont automatiquement inclus dans les requêtes HTTP vers le serveur qui les a posés. Donc ce système profite de cette caractéristique pour inclure le token dans un cookie, token qui sera donc automatiquement renvoyé à chaque requête vers le serveur. Côté serveur, il ne reste plus qu'à récupérer le token et à retrouver la session associée.

Je ne sais pas quelle librairie/framework tu utilise côté client pour envoyer tes requêtes HTTP, mais si elle/il gère les cookies, je te conseille de t'orienter vers cette solution.

[gilloddon]

Merci pour la suggestion, je verrais ça en temps voulu car je ne sais pas encore comment j'enverrais des requêtes HTTP depuis mon client lourd en C++.

Par contre, le transport du token n'est pas vraiment un problème, c'est plutôt la génération et la gestion du token côté serveur.
En PHP, je suppose qu'on utilise souvent le système de session, mais en Node.js je ne sais pas s'il existe un tel système.

[Spartacusply]

La génération du token en javascript (ou node.js c'est la même) n'est pas tellement un problème, c'est juste que de toutes façons il te faudra le stocker côté serveur. Donc autant le faire de ce côté là dès le début, ce sera bien plus facile et bien plus pratique à manipuler par la suite.