Comment vérifier lorsqu'un utilisateur quitte une application ASP.NET

Dans ASP.NET, je cherche un moyen d'auditer un utilisateur qui quitte mon application. Pour être précis, je voudrais insérer un enregistrement 'logout' dans une table d'audit dans SQL Server lorsque la session de l'utilisateur est abandonnée/détruite pour une raison quelconque (pas nécessairement à cause d'un appel à session.abandon)

J'ai une classe 'SessionHelper' qui gère les setters/getters de la session.

J'ai essayé de publier dans Session_End dans Global.asax, mais il n'a jamais déclenché cet événement même après l'expiration du délai.

J'ai essayé de redéfinir 'finalize' dans la classe SessionHelper et de le faire là quand la classe est détruite, mais elle n'a pas non plus déclenché cet évènement.

J'essaierais d'implémenter IDisposable dans le SessionHelper, mais je ne sais pas où l'appeler pour qu'il soit toujours appelé.

Quelle est la bonne façon d'auditer un utilisateur quittant votre application ASP.NET?

Je vous remercie!

2

3 Réponses

L'événement Session_End est uniquement déclenché si vous avez des sessions InProc. La gestion de session SQL ou d'état du serveur ne déclenchera pas cet événement. Si vous le pouvez, revenez aux sessions InProc et utilisez cet événement.

En dehors de cela, vous n'obtiendrez pas de très bonnes solutions. ASP.NET n'offre pas un moyen de regarder la liste actuelle des sessions sur le serveur (au moins, aucune façon que les utilisateurs de StackOverflow savent, puisque j'ai déjà posé la question), de sorte que vous ne pouvez pas utiliser un travail pour vérifiez quand ils sont détruits.

La meilleure chose à faire serait d'avoir un "dernier temps d'accès" stocké quelque part pour vos utilisateurs et de l'utiliser pour détecter un délai d'expiration de la session. La mise en œuvre d'un tel travail est cependant compliquée (vous pouvez manquer des événements de déconnexion si un utilisateur se connecte/se déconnecte rapidement par exemple) ...

Donc, pas de solution parfaite ici.

2
ajouté

Notez bien la "bonne façon" mais voici comment je l'ai fait dans le passé.

Avoir une date "est active": horodatage associé à l'enregistrement utilisateur dans la base de données. Chaque fois que l'utilisateur accède à une page, celle-ci est mise à jour à l'heure actuelle. Si quelqu'un n'a pas accédé à la page dans les 15 minutes, alors cet utilisateur est enregistré comme un événement de «déconnexion» et l'horodatage est défini sur NULL.

2
ajouté
Je fais quelque chose de similaire, j'utilise la gestion de session basée sur SQL et ai une dernière colonne accédée dans la table contenant mes données de session. Il existe un proc stocké qui s'exécute chaque fois qu'un enregistrement de session est modifié, ce qui nettoie les tables des lignes de session inutilisées plus longtemps qu'une valeur TIMEOUT prédéfinie.
ajouté l'auteur stephenbayer, source

Au mieux, votre enregistrement de déconnexion sera une supposition intelligente, même si vous faites fonctionner correctement les événements de session, lorsque l'utilisateur a quitté votre site/application. Une technique que vous pouvez utiliser est de placer l'heure de déconnexion dans la base de données lorsque l'utilisateur se connecte, et de continuer à mettre à jour l'enregistrement avec une heure future, car ils utilisent le système. Voici le schéma général d'une table de session que j'ai utilisée récemment:

[Id]  [Uid]    [LoginInOn]        [ExpiresOn]  
 1    johndoe  10/14/2008 10:47   10/14/2008 11:07  

Dans ce tableau, je continue à mettre à jour la colonne ExpiresOn lorsque l'utilisateur interagit avec l'application (heure actuelle + 20 minutes). S'ils tentent d'interagir après ExpiresOn, je sais qu'ils ont été inactifs pendant 20 minutes et forcent une nouvelle connexion. À des fins de génération de rapports, je sais que l'utilisateur s'est déconnecté si l'heure actuelle est supérieure à ExpiresOn. Vous pouvez devenir plus complexe que cela. Par exemple, je déplace mes données du tableau des sessions répertoriées ci-dessus vers un tableau de rapport avec un processus régulier. C'est juste pour garder la table des sessions petite, car beaucoup de choses interagissent avec elle.

1
ajouté