Les utilisateurs sont obligés de se reconnecter aléatoirement, avant que les valeurs de session et de délai d'expiration de ticket d'authentification ne soient atteintes

Question

Je reçois des rapports et des plaintes de mon utilisateur indiquant qu'ils utiliseront un écran et seront immédiatement redirigés vers l'écran de connexion. demande. Cela n'arrive pas tout le temps mais au hasard. Après avoir examiné le serveur Web, l'erreur qui apparaît dans le journal des événements d'application est la suivante:

Code d'événement: 4005 Message d'événement: L'authentification par formulaire a échoué pour la demande. Raison: le ticket fourni a expiré. Tout ce que je lis commence par des questions sur les jardins Web ou l'équilibrage de charge. Nous n'utilisons pas l'un ou l'autre. Nous sommes un seul serveur Windows 2003 (système d'exploitation 32 bits, matériel 64 bits) avec IIS6. C'est le seul site sur ce serveur aussi.

Ce comportement ne génère aucune exception d'application ni aucun problème visible pour l'utilisateur. Ils sont simplement ramenés à l'écran de connexion et sont obligés de se connecter. Comme vous pouvez l'imaginer, cela est extrêmement ennuyeux et contre-productif pour nos utilisateurs.

Voici ce que j'ai mis dans mon web.config pour l'application à la racine:

<authentication mode="Forms"> 
     <forms name=".TcaNet" 
     protection="All" 
     timeout="40" 
     loginUrl="~/Login.aspx" 
     defaultUrl="~/MyHome.aspx" 
     path="/" 
     slidingExpiration="true" 
     requireSSL="false" /> 
    </authentication> 

J'ai aussi lu que si vous avez des emplacements configuration qui n'existent plus ou sont fausses, vous pourriez avoir des problèmes . Mes attributs de chemin sont tous les répertoires valides afin que ne devrait pas être le problème:

<location path="js"> 
    <system.web> 
     <authorization> 
     <allow users="*" /> 
     </authorization> 
    </system.web> 
    </location> 
    <location path="images"> 
    <system.web> 
     <authorization> 
     <allow users="*" /> 
     </authorization> 
    </system.web> 
    </location> 
    <location path="anon"> 
    <system.web> 
     <authorization> 
     <allow users="*" /> 
     </authorization> 
    </system.web> 
    </location> 
    <location path="App_Themes"> 
    <system.web> 
     <authorization> 
     <allow users="*" /> 
     </authorization> 
    </system.web> 
    </location> 
    <location path="NonSSL"> 
    <system.web> 
     <authorization> 
     <allow users="*" /> 
     </authorization> 
    </system.web> 
    </location> 

La seule chose que je ne suis pas clair est si ma valeur de délai d'attente dans la propriété de formulaires pour le billet d'auth doit être le même comme valeur de délai d'attente de session (définie dans la configuration de l'application dans IIS). J'ai lu certaines choses qui disent que vous devriez avoir le délai d'authentification plus court (40) que le délai d'expiration de la session (45) pour éviter d'éventuelles complications. Dans les deux cas, nous avons des utilisateurs qui sont redirigés vers l'écran de connexion une minute ou deux après leur dernière action. Donc, la session ne devrait définitivement pas expirer. Mise à jour 2/23/09: J'ai depuis paramétré le délai d'attente de la session et le délai d'expiration des tickets d'authentification à 45 et le problème semble toujours se produire.

Le seul autre web.config de l'application se trouve dans 1 répertoire virtuel qui héberge le serveur de communauté. Que les paramètres d'authentification de web.config sont les suivantes:

<authentication mode="Forms"> 
      <forms name=".TcaNet" 
      protection="All" 
      timeout="40" 
      loginUrl="~/Login.aspx" 
      defaultUrl="~/MyHome.aspx" 
      path="/" 
      slidingExpiration="true" 
      requireSSL="true" /> 
     </authentication> 

Et pendant que je ne crois pas qu'il applique à moins que vous êtes dans un jardin Web, je les deux machines valeurs clés définies dans les deux fichiers web.config pour être le même (enlevé pour plus de commodité):

<machineKey 
     validationKey="<MYVALIDATIONKEYHERE>" 
     decryptionKey="<MYDECRYPTIONKEYHERE>" 
     validation="SHA1" /> 

<machineKey 
     validationKey="<MYVALIDATIONKEYHERE>" 
     decryptionKey="<MYDECRYPTIONKEYHERE>" 
     validation="SHA1"/> 

Toute aide avec ceci serait grandement appréciée. Cela semble être l'un de ces problèmes qui donne une tonne de résultats Google, dont aucun ne semble être adapté à ma situation jusqu'à présent.

Answer 1

1.) Vérifiez la fréquence de recyclage de votre processus iis. (Activer logging et check your settings). Après un recyclage, en utilisant le magasin de session proc par défaut, la session est perdue. 2. Votre application engendre-t-elle des Threads pouvant provoquer une exception (qui ne sont pas affichés pour l'utilisateur)? Parce que si cette situation existe, l'IIS recycle les processus beaucoup plus souvent.

Answer 2

Il peut également être utile de vérifier la propriété Nombre maximal de processus de travail pour votre pool d'applications. Si vous utilisez une session de mémoire et que vous en avez plusieurs en tant que processus de travail max, vous pouvez trouver des problèmes de session car une requête utilisateur est traitée par un thread différent qui ne connaît pas sa session.

Answer 3

Étant donné que vous avez noté que vous utilisez un nom de domaine complet très spécifique pour votre site, avez-vous d'autres applications .Net exécutées sous le même nom de domaine complet uniquement par des chemins d'accès virtuels différents? Le nom du cookie d'authentification peut être le même pour les deux applications, mais le jeton sera différent. Donc, si je me connecte sur www.domain.com puis sur www.domain.com/app2, je n'aurai plus d'authentification correcte pour app1.

Answer 4

Je viens de finir de traiter ce problème précis, exactement comme décrit dans la question et le problème était une config manquant dans web.config. Lors de l'utilisation de formsAuthentication, vous devez arrêter l'authentification de la session, car le cookie en est désormais responsable.

Cette ligne doit être ajoutée (ou mis à jour) dans votre configuration web, dans l'élément « system.web »

<sessionState mode="Off"> 

sessionState et FormsAuthentication ne doivent pas être actives. Je ne comprends pas les détails de la façon dont ils interfèrent les uns avec les autres, mais dans ce cas, il a produit des déconnexions aléatoires d'utilisateurs aléatoires à des moments aléatoires.

Answer 5

Notre site a trébuché avec le même problème pendant des années, mais hier, nous avons trouvé une solution, voir my question. En intervenant a proposé, j'ai essayé d'ajouter ceci à web.config:

<sessionState mode="InProc" timeout="60" /> 

Apparemment, le délai d'attente doit être à la fois dans sessionState et le billet. Voir aussi ms docu dans https://msdn.microsoft.com/en-us/library/ms178586.aspx

Pour mesurer plus précisément le délai d'attente réel en mode débogage, je l'ai trouvé très pratique pour ajouter Debug.WriteLine appels dans le fichier Global.asax.cs dans les méthodes Session_Start() et Session_End(), avec le temps de milliseconde ajouté à l'aide

string.Format("{0:HH:mm:ss.fff} - {1}", DateTime.Now, strMessage); 

afin que vous puissiez vous connecter, aller déjeuner, laisser la session expirer, et lire les horodatages à un moment opportun dans la fenêtre VisualStudio Output.