Was könnte ASP.NET FormsAuthentication Cookie Probleme abgesehen von Cookies verursachen, die ausgeschaltet werden?

Question

Benutzer melden Probleme beim Anmelden auf einer unserer ASP.NET-Sites. Wenn ich die IIS-Protokolle überprüfe, sieht es so aus, als ob der FormsAuthentication-Cookie nach der Anmeldung nicht von ihren Browsern zwischengespeichert wird.

Ich glaube nicht, sein so einfach wie ‚Benutzer ihren Browser keine Cookies akzeptieren gesetzt haben‘, weil:
a) Wenn Cookies im Allgemeinen wurde nicht für ihren Browser arbeitet, würden sie nie so weit gekommen wie sie in dem Prozess haben - die ASP.NET Session-Cookies scheinen zum Beispiel in Ordnung zu sein.
b) Diese sind im Allgemeinen nicht die Art von Benutzern, die sogar wissen würden, wie man Kekse abstellt.

Also ich denke, es ist etwas anderes sein muss. Welche Art von Problemen kann dazu führen, dass ASP.NET FormsAuthentication-Cookies nicht mehr funktionieren, , abgesehen von Benutzern, die einfach ihren Browser so einstellen, dass Cookies abgelehnt werden?

bearbeiten: Zum Beispiel This answer to another question schlägt vor, dass manchmal FormsAuthentication Cookies fallengelassen werden, weil sie zu groß sind - vielleicht kann jemand etwas Licht darauf werfen?

edit: das FormsAuthentication Cookie für einen unserer Seiten ist 233 Bytes - ist, dass ein wenig zu groß? Kann es kleiner gemacht werden? Vielleicht würde das helfen.

edit: Ich stelle fest, der Code FormsAuthentication.SetAuthCookie() und Response.Redirect() statt FormsAuthentication.RedirectFromLoginPage() verwendet - das zusammenhängen könnte?

Answer 1

Ist es möglich, der Benutzer die Webserver über 2 verschiedene Domänen zugreifen? Wenn ich zum Beispiel auf www.foo.com gehe und einen Authentifizierungscookie erhalte und dann auf www.bar.com weiterleite, enthält die an www.bar.com gesendete Anfrage sicherlich nicht den von www.foo.com gesetzten Cookie .

Dieses Problem würde auch passieren, wenn Sie das Cookie bei htp gesetzt: //login.foo.com, dann auf htp umleiten: //content.foo.com. Ich glaube jedoch, dass der Cookie mit einem Platzhalter konfiguriert werden könnte, so dass er für * .foo.com gelten würde.

Bearbeiten: absichtlich falsch geschrieben "http", so dass es nicht wirklich klickbare Müll-Links in dieser Antwort gibt. :)

Answer 2

Es gibt einen Idle Timeout - protokollieren sie in, dann eine Zeit lang nicht etwas zu tun, dann wieder auf die Website zugreifen wollen? Sie könnten das überprüfen. Und, sehen Sie, ob das Zeitlimit auf eine gleitende Zeitüberschreitung (z. B. 20 Minuten nach der letzten Anforderung) oder eine feste Zeitüberschreitung (z. B. 20 Minuten nach der Anmeldung) eingestellt ist. Ich denke, das Zeitlimit ist nicht die Standardeinstellung.

Answer 3

Wenn Ihre Site in einer Webfarm ausgeführt wird, müssen Sie möglicherweise machine keys auf allen Servern festlegen, oder wenn der Benutzer den Server wechselt, kann das Authentifizierungsticket möglicherweise nicht entschlüsselt werden. Der Unterschied zwischen RedirectFromLoginPage() und SetAuthCookie gefolgt von Response.Redirect() ist, dass das erste funktioniert auch, wenn Cookies deaktiviert sind

Answer 4

Versuchen Sie, die folgenden Schritte aus.

http://blogs.msdn.com/b/rahulso/archive/2007/01/17/troubleshooting-cookies-a-case-study.aspx

Ich schrieb diese lange zurück, aber wenn man es genau die Chancen sind, folgen hoch, dass Sie die Ursache finden.

Isolation der Grundursache ist hier der Schlüssel. Das Problem zu beheben wird ziemlich einfach sein, sobald Sie herausfinden, warum es überhaupt passiert.

Rahul

www.dotnetscraps.com

Answer 5

Könnte es sein, dass der Webserver-Name oder Teil des DNS-Namens einen Unterstrich enthält?

zB:

www2_http.mydomain.com

Ich erinnere mich, dieses Problem bei einer gewissen Entwicklungsstufe, wo die Sitzungen regelmäßig nicht verhalten würden. Durch das Entfernen des Unterstrichs aus dem Domänennamen der Maschine wurde das Problem für mich behoben.

Grüße

Answer 6

Ich habe ein ähnliches Problem hat (nicht mit dem FormsAuthentication Cookie, aber mit einer klebrigen Loadbalancer Cookie), da der Server keine richtige Zeit/Zeitzone Konfiguration hat, so gab es Fälle, wenn die Das Cookie-Ablaufdatum war älter als die aktuelle Zeit auf dem Benutzercomputer.

siehe hier: How do expire values work for cookies and caching?

hoffen, dass es

Answer 7

Sind hilft Ihnen, mehr als eine Domäne verwenden, um die gleiche Web-Anwendung zu sprechen? Denken Sie daran, dass Cookies Domain-spezifisch sind, www.mydomain.com <> www.mydomain.net <> my.domain.net.

Ein Stich im Dunkeln, haben Sie Maschinentasten in Ihren Webconfigs?