Le stockage du token ne stocke pas réellement l'état de connexion, mais le token permettant d'appeler l'interface. Tant que le token existe et n'a pas expiré, il est considéré comme étant toujours dans l'état de connexion.
Le jeton est utilisé pour vérifier la connexion de l'utilisateur. Il s'agit simplement d'un identifiant et le contenu spécifique se trouve côté serveur.
Il n'y a en fait pas de "statut" dans le statut de connexion. Parce que http lui-même est apatride. Par conséquent, chaque fois que le client lance une requête auprès du serveur, celui-ci doit s'authentifier.
Première fois : L'utilisateur fournit une authentification par nom d'utilisateur et mot de passe, et le serveur authentifie l'utilisateur via "nom d'utilisateur + mot de passe". Après passage, le serveur générera un identifiant d'authentification. Le serveur enregistrera cet ID d'authentification et répondra au client avec l'ID d'authentification. Le client enregistrera également cet ID d'authentification.
La deuxième à la nième fois : l'agent client utilise l'ID d'authentification enregistré pour lancer une requête au serveur, et le serveur authentifie l'utilisateur via "l'ID d'authentification".
Quant à savoir si l'identification d'authentification est stockée dans le cookie ou le stockage local du client, et s'il faut utiliser le mécanisme de session ou un mécanisme de jeton personnalisé. Il s'agit simplement d'un plan de mise en œuvre spécifique.
Si vous utilisez un navigateur, généralement cookie+session. S'il s'agit d'une interface, telle qu'une application, un mécanisme de jeton est généralement personnalisé.
Pourquoi tu fais ça ? Parce que chaque demande nécessite que les utilisateurs saisissent leur nom d'utilisateur et leur mot de passe, les utilisateurs deviendront fous.
Donc l'agent client (navigateur), remplace l'utilisateur. L'ID d'authentification remplace le nom d'utilisateur et le mot de passe.
Diverses solutions techniques de mise en œuvre ne sont rien d'autre que des considérations de sécurité et d'efficacité
Essentiellement, ce n'est pas différent de l'utilisateur qui saisit son nom d'utilisateur et son mot de passe à chaque fois
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Le stockage du token ne stocke pas réellement l'état de connexion, mais le token permettant d'appeler l'interface. Tant que le token existe et n'a pas expiré, il est considéré comme étant toujours dans l'état de connexion.
Enregistrer dans la session du serveur
Le jeton est utilisé pour vérifier la connexion de l'utilisateur. Il s'agit simplement d'un identifiant et le contenu spécifique se trouve côté serveur.
Il n'y a en fait pas de "statut" dans le statut de connexion. Parce que http lui-même est apatride. Par conséquent, chaque fois que le client lance une requête auprès du serveur, celui-ci doit s'authentifier.
Première fois : L'utilisateur fournit une authentification par nom d'utilisateur et mot de passe, et le serveur authentifie l'utilisateur via "nom d'utilisateur + mot de passe". Après passage, le serveur générera un identifiant d'authentification. Le serveur enregistrera cet ID d'authentification et répondra au client avec l'ID d'authentification. Le client enregistrera également cet ID d'authentification.
La deuxième à la nième fois : l'agent client utilise l'ID d'authentification enregistré pour lancer une requête au serveur, et le serveur authentifie l'utilisateur via "l'ID d'authentification".
Quant à savoir si l'identification d'authentification est stockée dans le cookie ou le stockage local du client, et s'il faut utiliser le mécanisme de session ou un mécanisme de jeton personnalisé. Il s'agit simplement d'un plan de mise en œuvre spécifique.
Si vous utilisez un navigateur, généralement cookie+session. S'il s'agit d'une interface, telle qu'une application, un mécanisme de jeton est généralement personnalisé.
Pourquoi tu fais ça ? Parce que chaque demande nécessite que les utilisateurs saisissent leur nom d'utilisateur et leur mot de passe, les utilisateurs deviendront fous.
Donc l'agent client (navigateur), remplace l'utilisateur. L'ID d'authentification remplace le nom d'utilisateur et le mot de passe.
Diverses solutions techniques de mise en œuvre ne sont rien d'autre que des considérations de sécurité et d'efficacité
Essentiellement, ce n'est pas différent de l'utilisateur qui saisit son nom d'utilisateur et son mot de passe à chaque fois