Java Comment invalider une session utilisateur lorsqu'il se connecte deux fois avec le même identifiant

Question

Hallo all. J'ai trouvé cette discussion intéressante sur la façon d'invalider une session utilisateur quand il se connecte deux fois.

How to invalidate an user session when he logs twice with the same credentials

J'ai un environnement légèrement différent mais je résoudre le même problème. Les différences sont que je n'utilise pas JSF et que mon application est en cours d'exécution sur un cluster.

Je suis prêt à appliquer ce modèle, mais je me demandais où devrais-je enregistrer la carte de l'utilisateur? Existe-t-il un contexte visible pour toutes les machines du cluster?

Merci à l'avance

Answer 1

Le point sur l'exécution de l'application sur un cluster est plus important et pertinent que l'absence de JSF.

L'exigence imposée par le cluster sur toute solution est que la solution nécessite l'utilisation d'un stockage partagé accessible à tous les membres du cluster. Il y a plusieurs solutions possibles qui compte pour cette exigence:

• Utilisez une base de données pour stocker la liste de tous les utilisateurs connectés (avec un ID pour identifier leur session; JSESSIONID pourrait être utilisé, mais il vaut mieux utiliser un identifiant qui est garanti unique pour tous les membres du cluster). Même une combinaison d'ID utilisateur et d'ID de membre de cluster fera l'affaire. C'est le plus simple, mais il vous faudra tester la façon dont votre code gère le basculement (vous devrez peut-être mettre à jour les entrées dans la base de données lors du basculement de session).
• Utilisez le contexte d'application (le ServletContext). C'est une solution possible, mais pas recommandée du tout. Bien que le contexte de l'application soit tenu à jour dans tous les membres du cluster, il existe un coût pour maintenir le contenu à jour (augmentation du trafic réseau entre les membres du cluster).
• Utilisez une solution de mise en cache distribuée telle que Terracotta ou Coherence. Cette solution est presque la même que la précédente, sauf que la session "map" ne sera pas gérée dans le ServletContext. Le trafic réseau est lié à la mise à jour du cache distribué.