mixup variable de session dans ASP.NET?

Question

Est-il possible pour ASP.NET de mélanger quel utilisateur est associé à quelle variable de session sur le serveur? Les variables de session sont-elles immuablement liées à l’utilisateur original qui les a créées dans le temps, l’espace & dimension?

Answer 1

Pour répondre à votre question initiale: Les sessions sont associées à un identifiant placé dans un cookie. Cet identifiant est généré à l'aide de routines cryptographiques à nombres aléatoires. Il n’est pas garanti qu’il soit unique, mais il est très peu probable qu’il soit reproduit au cours de la durée d’une session. Même si vos sessions durent des journées complètes de travail. Il faudrait probablement des années pour qu'un site très populaire génère même une clé en double (aucune statistique ni aucun fait à l'appui).

Cela dit, il ne semble pas que votre problème soit lié à la confusion des valeurs de session. La première chose que je commencerais à regarder est la mise en commun des connexions. ADO met en pool les connexions par défaut, mais si vous demandez une connexion avec un nom d'utilisateur / mot de passe qui ne se trouve pas dans le pool, vous devez en créer une nouvelle. Astuce qui pourrait constituer un goulot d'étranglement dans les performances futures si votre site est très volumineux. Cela fait longtemps que je ne travaille pas avec SQL Server, Oracle permet de changer l’identité de l’utilisateur. Je serais surpris s'il n'y avait pas d'équivalent dans SQL Server. Vous pouvez essayer de vous connecter à votre base de données avec un nom d’utilisateur / mot de passe générique, puis d’exécuter cet appel de commutateur d’identité avant de rendre la connexion au reste de votre code.

Answer 2

Cela dépend de votre fournisseur de session. Si vous avez annulé la génération de clé de session d’une manière qui n’est plus unique, plusieurs utilisateurs peuvent accéder à la même session.

Quel comportement observez-vous? Et êtes-vous sûr qu'il n'y a pas de statique en jeu avec les variables dont vous parlez?

Answer 3

alors que tout est possible. . . .

Non, sauf si vous enregistrez l'état de la session sur un serveur SQL ou un autre stockage hors processus, puis le manipulez. . .

Answer 4

La session étant liée à un cookie utilisateur, les chances de gâchis dans un scénario normal sont très peu probables. Toutefois, des problèmes peuvent survenir si vous utilisez l'état de session distribuée.

Answer 5

Ce n'est pas possible. Les sessions sont liées au créateur.

Voulez-vous mélanger, ou avez-vous un cas où cela ressemble à mélangé?

Answer 6

Plus d'informations:

J'ai une application qui extrait l'ID utilisateur / mot de passe de la page de connexion et le stocke dans une variable de session. Je le plop dans ma chaîne de connexion pour faire des appels à SQL Server.

Quand une table est mise à jour, nous utilisons 'utilisateur_système' dans la base de données pour identifier le dernier utilisateur mis à jour par. Nous constatons un comportement étrange dans lequel l'utilisateur que nous nous attendons à répertorier est incorrect et qu'il montre quelqu'un d'autre.

Answer 7

Pouvez-vous afficher le débogueur et voir si la valeur correcte est effectivement transmise à cette chaîne de connexion? Cela vous aiderait rapidement à identifier le côté du problème.

Assurez-vous également qu'aucun des codes de connexion ne possède de propriétés statiques pour la connexion ou l'utilisateur, ou qu'un utilisateur puisse voir sa connexion remplacée par celle de l'utilisateur le plus récent avant le déclenchement de la mise à jour.

Answer 8

Je suppose que vous réutilisez un champ statique sur une classe pour contenir la chaîne de connexion. Ces champs statiques sont réutilisés dans plusieurs demandes IIS, vous ne verrez donc probablement que le dernier utilisateur connecté dans la "dernière mise à jour par".

BTW, sauf si vous avez vraiment une bonne raison de le faire, vous ne devriez pas vous connecter à la base de données comme ceci. Vous vous empêchez d'utiliser le regroupement de connexions, ce qui pourrait nuire aux performances sous des charges élevées.