2009-11-25 4 views
0

J'ai une application ASP.net 2.0 sur mon serveur au travail. Lorsque je suis sur la boîte et la navigation (soit http://serverName ou http://localhost) le site je peux me connecter avec l'authentification par formulaires et naviguer sur le site sans problème.Pourquoi l'authentification des formulaires ASP.net me déconnecte (lorsqu'elle ne se connecte pas directement sur ma boîte)?

L'instant où je navigue sur ce serveur à partir de mon intranet, je peux toujours me connecter, mais chaque fois que je clique sur un lien sur la page d'accueil, on me demande de me connecter à nouveau. Je peux accéder à la page d'accueil, donc l'authentification fonctionne, mais je suis immédiatement redirigé vers la page de connexion après cela. J'utilise le même ID utilisateur dans les deux cas.

Il ne s'agit pas d'un cas où les cookies du navigateur ne sont pas activés, cela provient de plusieurs stations de travail différentes, utilisant IE et Firefox. J'ai une autre application ASP.Net fonctionnant sur ma même machine, et cela fonctionne bien localement ou à l'extérieur. (Il s'agit d'une ancienne version de la même application, qui utilise également l'authentification par formulaires.)

J'utilise des sessions inproc, pas des sessions sans cookie non plus. Essentiellement le réglage de la session qui sort tout de suite de la boîte.

La configuration de l'authentification par formulaire sur les deux répertoires virtuels (ancienne et nouvelle application) est la meilleure que je puisse dire, et je n'ai pas de pare-feu sur la machine. Je ne peux pas expliquer cela, et si vous avez des suggestions, je peux vous en être reconnaissant. Merci!

Édition: Il semble que cela se produise lorsque j'ai le tag dans mon web.config réglé sur "On" ou "RemoteOnly". Je vois de ieHttpHeaders qu'il y a un appel à WebResource.axd, alors la prochaine page appelée est ma page d'erreur personnalisée. Lorsque je place off customErrors, les choses fonctionnent comme prévu. Il semble donc que l'erreur provient de WebResource.axd d'une manière ou d'une autre.

Malheureusement, la page Page_Load de la page d'erreur personnalisée contient très peu d'informations. Les arguments de l'événement sont null et l'expéditeur est ASP.error_aspx, mais je ne vois pas beaucoup d'informations dedans.

Si cela vous dit quelque chose et si vous avez des idées à faire en ce qui concerne le débogage, je suis heureux de vous écouter. Merci encore.

+0

Une chance de résoudre ce problème? Y a-t-il des exceptions dans le journal système? Pouvez-vous publier le journal IIS pour cette transaction pour voir exactement ce qui a été appelé et les codes d'état? – Greg

+0

Salut Greg - merci pour votre intérêt. En fait, je n'ai trouvé aucune exception dans le système ou d'autres journaux. En fait, nous n'avons jamais compris, car le passage de la balise customErrors dans web.config à "Off" de "On" ou "RemoteOnly" était assez bon pour nous tenir. J'aimerais avoir de meilleures infos à partager. (Très probablement, notre routine d'erreur personnalisée lançait une exception enfouie, mais nous ne pouvions pas la comprendre.) – larryq

+0

Désolé de l'entendre. C'est très bizarre. – Greg

Répondre

1

Je mettais à jour un ancien site pour utiliser des données dynamiques, ces deux sites utilisaient l'authentification par formulaire et je les testais localement.

Problème: Lorsque l'on compare site & Site B dans mon navigateur je trouve quand je suis passé de l'utilisation du site utiliser du site B je devais vous reconnecter Site B et vice versa.

Solution: Dans mon enquête à ce que j'ai découvert ce qui était à l'origine ce phénomène.Un site & du site B avait le même nom de cookie d'authentification

site

<forms name="form1" loginUrl="login.aspx" path="/" > 
</forms> 

Site B

<forms name="form1" loginUrl="login.aspx" path="/" > 
</forms> 

J'ai changé les noms d'être unique et qui a résolu la question.

site

<forms name="sitea" loginUrl="login.aspx" path="/" > 
</forms> 

Site B

<forms name="siteb" loginUrl="login.aspx" path="/" > 
</forms> 

Remarque: http: // localhost /SiteA & http: // localhost /SiteB sont hébergés sur le même site Web (localhost) afin que le cookie d'authentification soit en cours de surcharge.

Questions connexes