ASP.NET Single Login - La distribution de la session est-elle la réponse?

Question

Nous avons 5 serveurs Web équilibrés avec différents sites Web. Ce que j'essaie de faire, c'est d'assurer une connexion unique. , c'est-à-dire que le même compte d'utilisateur ne peut pas se connecter au même site Web plus d'une fois à la fois.

La méthode que je considère pour résoudre ceci, est de partager la session parmi les serveurs ainsi je peux commander quelle session est assignée à quel compte. Je peux alors contrôler mes identifiants. Si un utilisateur se connecte et qu'une session est déjà affectée à son compte utilisateur, je peux simplement expirer la première session ou rejeter la connexion. Je ne veux pas perdre l'avantage des serveurs équilibrés, donc utiliser un serveur Sql unique comme serveur d'état de session, ou un seul serveur pour gérer la connexion n'est pas une option.

Est-ce que la session distribuée (quelque chose comme Scaleout Sofware) est la bonne approche pour y parvenir?

Ou existe-t-il un autre mécanisme permettant de gérer une connexion unique dont je suis parfaitement ignorant?

Answer 1

Vous avez deux séries de problèmes ici:
1) qui permet à un utilisateur connecté dans un scénario agricole web
2) Détection utilisateur logoff

Pour résoudre la première, la seule solution est une centrale de stockage pour une sorte de l'état utilisateur, en utilisant un serveur central pour stocker la session ASP.Net ou un autre type d'état utilisateur centralisé. Ce stockage central peut être SQL Server en utilisant la gestion native de l'état de session (btw aussi Oracle, d'Oracle 11, peut supporter le stockage de session), le service AspState ou une solution externe, comme ScaleOut (comme vous l'avez dit) ou son alternative open source memcached (Voir https://sourceforge.net/projects/memcacheddotnet/). Vous pouvez également concevoir un service Web centralisé simple qui vérifie les connexions actives par rapport à une base de données SQL Server. Vous pouvez ainsi créer rapidement des outils de création de rapports sur les utilisateurs connectés, etc. Un vrai problème, à mon avis, réside dans la deuxième partie, à savoir que vous devez gérer les différents scénarios de «fermeture de session erronée» disponibles dans un monde Web (comme fermer le navigateur en raison d'un blocage ou de l'arrêt des applications). sans se déconnecter), ce qui vous permet de travailler avec un utilisateur qui a déjà activé une ancienne session (comme vous l'avez dit, l'expiration de la première session peut fonctionner). Gardez également à l'esprit que l'utilisation d'un serveur d'état tel que SQL Server ne vous fera pas perdre les serveurs équilibrés, si vous voulez travailler sur un environnement de ferme Web et partager des sessions, seul le problème réside dans les performances. grand) et le coût impliqué dans l'utilisation de SQL Server si vous n'avez pas déjà la bonne licence.