Explication détaillée de l'utilisation de la session client dans Node.js programmation_node.js

Les sites Web statiques sont facilement évolutifs. Vous mettez simplement tout en cache et vous n'avez pas besoin de penser à combiner le contenu avec état de différents serveurs pour l'utilisateur.

Malheureusement, la plupart des applications Web utilisent du contenu avec état pour offrir une expérience personnalisée. Si votre application peut se connecter, elle doit mémoriser la session de l'utilisateur. La méthode de traitement classique est que le client définit un cookie contenant un identifiant de session unique et aléatoire, et les données de session identifiées sont enregistrées sur le serveur.

Extension des services avec état

Lorsque vous étendez votre service, vous avez certainement trois options :

1. Synchronisez les données de session entre différents serveurs
2. Différents serveurs se connectent à un centre de point unique (obtenir une session)
3. Assurez-vous que les utilisateurs accèdent au même serveur

Mais ils ont tous des défauts :

• La synchronisation des données augmente la surcharge de performances
• Le centre à point unique réduit l'évolutivité du système
• Que faire si le serveur visité par l'utilisateur la dernière fois a besoin d'une maintenance

Cependant, si vous y réfléchissez sous un autre angle, vous trouverez une quatrième option : sauvegarder les données de session sur le client

Séance client

Enregistrer la session sur le client présente certains avantages :

• Peu importe le serveur, les données de session sont valides
• Pas besoin de maintenir le statut du serveur
• Aucune synchronisation du serveur requise
• Ajoutez un nouveau serveur à volonté

Mais il y a un sérieux problème avec la session côté client : vous ne pouvez pas garantir que les utilisateurs ne falsifieront pas les données de session.

Par exemple, vous enregistrez l'identifiant de l'utilisateur dans un cookie. Il peut être facilement modifié par les utilisateurs pour accéder aux comptes d'autres personnes.

Cela semble nier la possibilité d'une session côté client, mais il existe un moyen de résoudre ce problème proprement : crypter et empaqueter les données de session (toujours stockées dans un cookie). De cette façon, il n'y a pas lieu de s'inquiéter de la modification par l'utilisateur des données de session, le serveur vérifiera les données.

En pratique, une clé de serveur cryptée est stockée dans le cookie. Ce n'est qu'après la vérification de la clé du serveur que vous avez le droit de lire et de modifier les données de session. Il s'agit de la session client.

Session client de nœud

Node.JS dispose d'une bibliothèque qui peut implémenter une session côté client : node-client-session. Il peut remplacer la session intégrée et le middleware cookieParser de Connect (un framework middleware Node).

Utilisation dans les applications du framework Express :

const clientSessions = require("client-sessions"); 

app.use(clientSessions({ secret: '0GBlJZ9EKBt2Zbi2flRPvztczCewBxXK' // 设置一个随机长字符串! })

Ensuite, ajoutez des propriétés à l'objet req.session :

app.get('/login', function (req, res){ req.session.username = 'JohnDoe'; });

Lire les attributs :

app.get('/', function (req, res){ res.send('Welcome ' + req.session.username); });

Utilisez la méthode de réinitialisation pour mettre fin à la session :

app.get('/logout', function (req, res) { req.session.reset(); });

Déconnectez-vous immédiatement de la session Persona

(Remarque : Persona est un système d'identité en ligne lancé par Mozzilla)

Contrairement à la session côté serveur, le problème avec la session côté client est que le serveur ne peut pas supprimer la session.

Dans l'architecture côté serveur, vous pouvez supprimer les données de session. La session identifiée par un cookie client peut ne pas exister. Cependant, dans l'architecture côté client, les données de session ne se trouvent pas côté serveur et rien ne garantit que les données de session seront supprimées sur chaque client. En d’autres termes, nous ne pouvons pas synchroniser l’état client (connecté) et l’état du serveur (déconnecté) de l’utilisateur.

Afin de pallier ce défaut, un délai d'expiration est ajouté à la Session client. Vérifiez le délai d'expiration avant de développer les données de session (chiffrées et empaquetées). S'il expire, supprimez les données de session et modifiez le statut de l'utilisateur (par exemple, déconnexion).

Le mécanisme d'expiration fonctionne bien dans de nombreuses applications (en particulier les exigences de délai d'expiration court). Par exemple, dans Persona, lorsque l'utilisateur découvre que le mot de passe a été menacé ou endommagé, nous devons fournir une méthode permettant à l'utilisateur de se déconnecter immédiatement des données de session.

Cela signifie conserver un peu d’informations sur l’état dans le backend du service. La façon dont nous gérons la déconnexion instantanée consiste à ajouter un jeton dans la table de données utilisateur et les données de session.

Chaque fois que l'API est appelée, le jeton dans les données de session est comparé au jeton dans la base de données. Sinon, renvoyez un message d'erreur et quittez l'utilisateur.

Cela ajoutera des opérations de base de données redondantes pour interroger le jeton. Heureusement, la plupart des appels d'API nécessitent la lecture du tableau de données utilisateur, il suffit donc d'apporter le jeton avec lui.