web-dev-qa-db-fra.com

Comment fonctionne le délai d'expiration de la session dans IIS 7?

Dans web.config, j'ai défini le délai d'expiration de sessionState sur 20 minutes. Selon MSDN, ce délai spécifie le nombre de minutes pendant lesquelles une session peut être inactive avant d'être abandonnée. Dans IIS 7, DefaultWebSite-> État de la session-> Paramètres des cookies-> Délai d'expiration automatiquement est rempli avec une valeur de délai définie dans web.config, qui dans mon cas est de 20 minutes. En outre, les pools d'applications -> DefaultAppPool-> Paramètres avancés-> idleTimeout, je le mets à 10 minutes.

Ensuite, j'ai fait deux tests: Premier test: je me suis connecté à mon application web à 15h45, au ralenti pendant 10 minutes. À 15h55, j'ai essayé d'utiliser mon application, j'ai été viré. Je pense que le idleTimeout entre en jeu.

Deuxième test: je me suis connecté à mon application web à 16h00, je joue avec l'application à 16h05, 16h10, 16h15 et 16h20. Je m'attendais à être expulsé à 16 h 20. Mais je ne l'étais pas. Je pensais que le délai d'expiration de l'état de la session (20 min) en IIS 7 est la durée maximale pendant laquelle une session utilisateur peut être active avant que l'agent Web ne demande à l'utilisateur de se réauthentifier. Apparemment, à partir de ce test , ce n'est pas le cas. Quelqu'un peut-il m'expliquer cela? Comment puis-je définir le délai d'expiration pour le cas ci-dessus?

asp.netiis-7timeoutsession-state
25
GLP

Le délai d'expiration de session est un délai d'expiration glissant qui est réinitialisé pour un utilisateur à la valeur configurée à chaque fois qu'il visite le serveur.

Le délai d'inactivité de l'application se déclenche s'il n'y a eu aucune demande à votre application pendant cette période.

Les scénarios habituels sont donc:

Time  | User A       | User B       | Session States
------+--------------+--------------+-------------------------------------------
12:00 | Visits Page1 |              | A: New Session, Time-out: 20 minutes
12:02 | Visits Page2 |              | A: Time-out reset: 20 minutes
12:10 |              | Visits Page1 | A: Time-out: 12 min; B: New: 20 minutes
12:15 |              | Visits Page2 | A: Time-out: 07 min; B: Time-out: 20 min
12:22 |              |              | A: times out; B: 13 min remaining
12:32 |              |              | Application Shuts Down (Idle time reached)
12:35 | Visits Page3 |              | A: New Session Starts

Si l'utilisateur A revenait sur le site après 12h22, il aurait une session complètement nouvelle et toutes les valeurs que vous y aviez stockées précédemment seraient perdues.

La seule façon de garantir qu'une session persiste pendant le redémarrage de l'application consiste à configurer un service SessionState ou des états de session SQL et à vérifier que vous avez configuré la machine.key afin que ce ne soit pas généré automatiquement chaque fois que le serveur redémarre.

Si vous utilisez les mécanismes standard ASP.NET pour l'authentification, ASP.NET enverra deux cookies à chaque utilisateur:

  1. Jeton d'authentification: contrôlé par le paramètre Délai d'authentification , permet à l'utilisateur d'être automatiquement connecté à votre site si le cookie n'a pas expiré, cela peut être fixe ou glissant, et par défaut à 30 minutes , ce qui signifie que leur jeton d'authentification peut faire face à une période "d'inactivité" plus longue que leur session.
  2. Jeton de session: contrôlé par le paramètre Délai d'expiration de la session, permet à votre application de stocker et d'accéder aux valeurs par utilisateur pendant la durée de leur visite.

Ces deux cookies sont chiffrés à l'aide de MachineKey - donc si votre application recycle et génère une nouvelle clé, aucun de ces jetons ne peut être déchiffré, ce qui oblige l'utilisateur à se connecter et à créer une nouvelle session.

Répondre aux commentaires:

  1. Le délai d'expiration de la session de 20 minutes concerne les éléments que vous avez placés dans l'objet de session des utilisateurs ( HttpSessionState ) à l'aide de la méthode Session.Add(string, object).
  2. Ça dépend. Si vous avez correctement configuré la machine.key , les jetons d'authentification seront toujours valides, et si vos sessions ne sont plus "InProc" ceux-ci persisteront également lors des redémarrages de l'application et seront toujours lisibles - voir les notes ci-dessus.
37
Zhaph - Ben Duguid