用户通过在单点登录服务器登陆，登录成功后，单点登录服务器分配给该用户一个ticket。然后单点登录服务器将该ticket做为key，用户名做为value，存储在redis中。通过判断该key是否是有效的来判断该用户会话有效。
后续会有服务通过向单点登录服务器发送一个ticket来验证该ticket是否有效，来判断该用户是否登录了。
但是这样会有个问题，某个用户肯能不停的登录，这样单点登录服务器每次都会将该ticket存储在redis中，虽然该ticket有过期时间，但有可能在短时间内在redis中写入大量的ticket。
不知这个有什么好的解决方法吗？
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Si vous parlez du fait que l'interface a été appelée de manière malveillante, elle appartient à la protection DDOS et ma réponse n'est pas applicable.
En fait, votre problème sera rencontré par toute personne ayant utilisé cette fonction. Autrement dit, si l'on estime que l'utilisateur s'est connecté, cela ne doit pas avoir été fait spécifiquement pour utiliser des cookies et des sessions. Dans le cas d'une connexion avec différents navigateurs, les cookies et les sessions sont inutiles.
Ce que j'ai fait à ce moment-là était de maintenir une autre relation dans redis : nom d'utilisateur-->ticket, afin que le ticket précédent puisse être trouvé en fonction du nom d'utilisateur, et qu'il puisse être déterminé si l'utilisateur s'est connecté à plusieurs reprises.
Je vais répondre à cette question en premier. Ajoutez un code de vérification lors de la connexion pour rendre plus difficile la connexion à la machine. C'est une méthode. Je me demande s'il existe d'autres méthodes ?
Après la connexion, le ticket doit être enregistré du côté de l'utilisateur, ou utiliser une session ou un cookie. Ensuite, lors de la déconnexion, le serveur peut récupérer le ticket et l'effacer. Ou lorsque l'utilisateur se reconnecte, le serveur peut également. obtenez le dernier ticket pour décider si une autre façon de détruire est d'utiliser l'ID utilisateur comme valeur clé pour enregistrer le ticket
Si vous vous connectez en continu sur une courte période, s'il s'agit d'une opération manuelle, vous pouvez être assuré que redis ne sera pas incapable de la maintenir.
S'il s'agit d'une attaque DDoS, vous devez ajouter une politique de protection à l'extérieur (routeur, pare-feu, serveur HTTP ou votre application).
Dans l'application, cela dépend de la manière dont vous allez définir un tel comportement de "connexion anormale". Par exemple, vous pouvez comparer les connexions sur une courte période de temps (vous pouvez personnaliser l'intervalle de temps), si la source est cohérente. (comme l'utilisateur de la Terre dans les 5 secondes) Connectez-vous à partir de 10 endroits différents). Après avoir jugé le comportement de connexion anormal, vous pouvez décider comment le gérer en fonction de la sensibilité de l'application (interdire le compte ? bloquer l'IP ? collecter preuves et appeler la police :-)
Déjà connecté, pourquoi voulez-vous le laisser se connecter à nouveau ? Y a-t-il un problème avec la logique ?