IISExpress Single-Thread?

Question

Je suis en train d'écrire une application .Net personnalisée qui utilise des revendications pour la sécurité, car nous traversons de nombreuses frontières - Web, API, traitement par lots et ainsi de suite. Pendant le développement, il y a des occasions où je vais créer quelque chose dans le système en étant connecté via Chrome puis je vais tester l'élément nouvellement créé via un autre compte dans Edge et en quelque sorte HttpContext.Current.User.Identity correspond à ma session Chrome. Je définis Thread.CurrentPrincipal dans les coulisses, mais j'ai toujours cru que toutes les requêtes dans IIS engendraient un nouveau thread, donc je n'arrive pas à comprendre pourquoi les requêtes Edge sont traitées comme s'il s'agissait des requêtes Chrome.

Est-il possible qu'il partage ces informations, car Visual Studio est en mode débogage?

Answer 1

Oui, IIS (et donc IISExpress, qui est empaqueté par IIS dans un format "application") est multithread. Cependant, vous avez fait des suppositions incorrectes.

D'abord, non. Une nouvelle requête NE génère PAS de nouveau thread, elle s'exécute sur un thread de pool de threads et ces pools de threads sont réutilisés après la fin de la requête précédente (ou, comme vous le verrez dans une minute, lorsqu'une requête asynchrone est attendue). Deuxièmement, vous ne devez PAS définir Thread.CurrentPrincipal car non seulement IIS est multithread, mais asynchrone. Cela signifie que si votre thread attend, lorsqu'il reprend, il peut s'exécuter sur un thread différent de celui sur lequel il a démarré.

Troisièmement, Thread.CurrentPrincipal est généralement l'identité de l'identité du processus de travail (ou AppPool), cela change le contexte de sécurité dans lequel le thread entier s'exécute. Une meilleure option est d'utiliser la classe WindowsImpersonationContext pour faire l'usurpation d'identité (ce que je suppose que vous essayez de faire).

WindowsIdentity clientId = (WindowsIdentity)User.Identity; 

// When 'using' block ends, the thread reverts back to previous Windows identity, 
// because under the hood WindowsImpersonationContext.Undo() is called by Dispose() 
using (WindowsImpersonationContext wic = clientId.Impersonate()) 
{ 
    // do your work that needs the identity 
} 

Si vous avez besoin de définir un principe personnalisé, vous devez généralement utiliser HttpContext.Current.User plutôt que Thread.CurrentPrincipal.