2010-07-19 5 views
0

Aidez-moi, je suis désespérée ici pour essayer de trouver le problème, et je ne sais pas par où commencer à le chercher.Étrange fermeture de session sur le site Web ASP.NET 3.5

Voici les symptômes:

Je l'ai remarqué, que lorsqu'un utilisateur se connecte le matin, il est immédiatement déconnecté, puis quand il se connecte à nouveau, tout va bien et il peut travailler sur le site.

De temps en temps, lorsque l'utilisateur clique sur un lien, la page prend beaucoup de temps à charger, mais elle ne se charge jamais réellement et l'utilisateur est redirigé vers la page de connexion.

De même, après qu'une exception s'est produite sur le site Web, l'utilisateur est ensuite redirigé vers la page de connexion. C'est comme si l'exception effaçait la session.

L'un de vous connaît-il une situation où cela pourrait se produire?

Le code que j'utilise dans chaque page dans mon application est la suivante:

If (Not User.Identity.IsAuthenticated) Then 
    Response.Redirect("../login2.aspx") 
End If 

' If session timeout then return to login screen ' 
If ((Session("LocationId") Is DBNull.Value) Or (Session("LocationId") Is Nothing)) 
Then 
    Response.Redirect("../login2.aspx") 
End If 

Le code dans le web.config:

<sessionState cookieless="false" timeout="600" /> 
<authentication mode="Forms"> 
<forms timeout="600" /> 
<system.web> 
    <authorization> 
     <allow users="*"/> 
    </authorization> 
</system.web> 

Répondre

1

Pourquoi utilisez-vous ce code dans chaque page?

L'autorisation .NET et l'authentification prennent normalement soin de toutes ces choses si vous l'avez configuré correctement.

1

liée à ce scénario * `

» .... après une exception a eu lieu sur le site, l'utilisateur est alors jeté à la page de connexion. Il est comme si l'exception efface en quelque sorte la session

Je connais une possible situation où il peut se produire. il est farfelue surtout dans un scenaio de production pour de multiples raisons, mais je l'ai vu arriver :-)

Si la session est en mémoire et que la journalisation est effectuée en écrivant dans un fichier journal situé dans le répertoire Bin de l'application, cela peut se produire car la modification du dossier bin de l'application Web entraîne le redémarrage de l'application. en session de mémoire se perdre.

Juste un scénario possible. Si votre session n'est pas en mémoire OU que votre mécanisme de journalisation n'est pas comme cela, cela ne s'applique pas à vous.

0

Je tournais à tous les experts nets de points là-bas parce que je suis vraiment désespéré,

laissez-moi donner un autre symptôme du problème, car il persiste encore,

le serveur est un serveur très forte - Intel Xeon avec un RAM de 3 Go, donc ce n'est probablement pas un problème de ressources.Lorsque l'utilisateur utilise le système en continu il n'y a pas de problème et il peut travailler librement, le problème se pose lorsque l'utilisateur quitte l'ordinateur (ou l'application d'ailleurs) pendant 5 minutes, puis quand il veut continuer à travailler et clique sur un lien dans l'application, elle est lancée sur la page de connexion. Quand elle essaie de se reconnecter, elle réussit, mais après avoir cliqué sur un autre lien, elle est rejetée à nouveau, puis quand elle se connecte, elle peut travailler librement et tout va bien.

D'une certaine manière, la session est en cours d'effacement lorsque le site est inactif. Permettez-moi de souligner que cela ne se produit pas lorsque je lance l'application dans Visual Studio, seulement dans IIS.

L'application a été converti en asp.net 2,0 à 3,5,

qui est, merci

0

Si vous utilisez juste la fonctionnalité de session normale en asp.net je crois que les temps de session après 15 -30 minutes d'inactivité (je n'utilise généralement pas de session donc je me souviens que c'est quelque part dans cette gamme). Chaque publication sur le serveur réinitialise cette minuterie, donc si un utilisateur est en train de faire des choses, alors il ne va pas frapper ce délai. Pour la page qui prend du temps à se charger, il est probablement dû au recyclage du processus de travail et cet utilisateur est le premier utilisateur à accéder au site après un recyclage qui déclenche IIS pour faire toutes ses tâches de compilation et servir la page qui provoque le retard. Cela se produit uniquement pour le premier visiteur après le recyclage d'un processus de travail. Vous pouvez modifier ce comportement dans IIS pour qu'il se produise sur une planification plutôt qu'après un certain temps passé sans activité. Votre processus de travail prendra alors plus de mémoire, mais selon votre environnement, cela ne sera peut-être pas un bon changement.

EDIT: Je devrais ajouter que le code que vous avez posté explique exactement pourquoi l'utilisateur est renvoyé à la page de connexion. Il vérifie pour s'assurer qu'il y a quelque chose dans la session et s'il n'y a rien là il renvoie l'utilisateur à la page de connexion. Ainsi, si elles sont inactives pendant trop longtemps, la session expire et l'utilisateur est renvoyé à la page de connexion par votre code. En outre, vous devez utiliser FormsAuthentication.RedirectToLoginPage(); pour votre redirection au lieu de Response.Redirect. De cette façon, après s'être connecté, ils retournent à la page qu'ils ont demandée à l'origine.

+1

30 par défaut. P.S. Jésus t'aime :) :) – abatishchev

+0

Salut, le truc bizarre, c'est que je mets le timeout de la session à 8 heures, donc la session ne devrait pas finir, mon pari est que quelques exceptions provoquent l'effacement de la session, et donc la déconnexion – vobs

0

Tout d'abord, vous devez refuser l'accès pour les utilisateurs (anonymes) non authentifiées:

<authorization> 
    <deny users="?" /> 
</authorization> 

Avez-vous configuré pages par défaut et connexion?

<authentication mode="Forms"> 
    <forms name=".ASPXFORMSAUTH" loginUrl="Login.aspx" defaultUrl="Default.aspx" slidingExpiration="true" timeout="30" /> 
</authentication> 

name définit le nom d'un cookie, utile si vous utilisez .NET 2.0 intégrée dans l'infrastructure de sécurité (rôles, membres, etc.)

slidingExpiration activé le comportement de délai normal - toute action de l'utilisateur remet à zéro délai d'attente

Questions connexes