Ich denke, ich habe das soweit reduziert, wie ich kann. Dies geschieht nur bei der Verwendung der Formularauthentifizierung und scheint nur in IE zu funktionieren. Bisher habe ich festgestellt, dass sowohl Chrome als auch Firefox das Problem verursachen. Ich habe eine sehr einfache ASP-Seite, die einen Zähler (gespeichert in einer Sitzungsvariablen) bei jedem Laden der Seite erhöht. Die Seite heißt test.asp
und erscheint in meinem Webstamm. Hier sind die Inhalte:
Und ich habe meine web.config
so weit wie möglich reduziert, während ich das Problem immer noch reproduziert habe. Hier sind seine Inhalte:
Ziemlich grundlegende Sachen hier. Ich habe test.asp
als "Login" -Seite festgelegt und runAllManagedModulesForAllRequests
aktiviert. Die Dinge funktionieren wie erwartet. Alle Anfragen werden wie erwartet auf test.asp
umgeleitet. Und test.asp
lädt gut, außer für was als nächstes passiert ...
So wird die Seite beim ersten Laden und nach dem Senden in IE (v11), Chrome (v44) und Firefox (v39) angezeigt:
Internet Explorer 11:
Google Chrome 44:
Mozilla Firefox 39:
Wenn ich [Submit]
anklicke, erwarte ich offensichtlich, dass der Wert Last Num
dem vorherigen This Num
entspricht. Aber das passiert nur im IE. In Chrome scheint es ein zusätzliches Inkrement zu sein. Und in Firefox scheint es zwei zu tun! Um die Dinge noch verwirrender zu machen, wird Firefox nach der ersten Eingabe immer um 1 erhöht. Chrome wird jedoch bei jeder Übermittlung doppelt erhöht.
Dies sind Standard-Browser-Installationen. Keine zusätzlichen Erweiterungen oder speziellen Konfigurationen. Cookies sind in allen drei Browsern aktiviert (Standard). Ich kann den Cookie ASPSESSIONID
mit den Entwicklertools jedes Browsers sehen. Und wie Sie in den Screenshots sehen können, wird Session ID
beim Laden der Seite erstellt und bleibt während der gesamten Sitzung konsistent.
Wenn ich weiter sende, sind die Ergebnisse gleich. IE funktioniert weiterhin ordnungsgemäß. Die anderen Browser werden weiterhin doppelt oder dreifach erhöht.
Wer hat dieses Problem schon einmal gesehen? Oder sehen, wo ich hier vielleicht falsch gelaufen bin? Ich habe versucht, cookieless="UseCookies"
im Abschnitt <forms>
von web.config
ebenfalls anzugeben.
Bearbeiten 1 - Testen an einem anderen Ort:
Alle meine Tests zu diesem Punkt wurden auf meinem lokalen PC: Windows 7 64-Bit mit IIS 7.5. Heute habe ich mich mit meinem eventuellen Testserver - einer Windows Server 2008 R2-Box, auch mit IIS 7.5 - verbunden und bekomme dort mit meiner Testseite die gleichen Ergebnisse.
Bearbeiten 2 - loginUrl-bezogen?
Die Verwendung einer neuen Seite, test2.asp
, mit demselben Inhalt (und einem expliziten Zugriff über ein <location>
-Element in meinem web.config
) funktioniert gut. Es scheint also loginUrl
verwandt zu sein? Vielleicht ruft es bei jeder Seitenanfrage die loginUrl
Seite hinter den Kulissen auf? Aber wieder, mit etwas Verbindung zu Chrome / Firefox ...
Bearbeiten 3 - Mehr Beweise:
Ich habe beschlossen, den Wert von This Num
bei jeder Ausführung der Seite zu protokollieren. Folgendes sehe ich:
Internet Explorer:
%Vor%Chrome:
%Vor%Firefox:
%Vor%Bearbeiten 4 - loginUrl-Seite Bei jeder Anforderung aufgerufen:
Es scheint, dass jede Art von Seitenanforderung bewirkt, dass test.asp
hinter den Kulissen ausgeführt wird, wodurch die Sitzungsvariable erhöht wird. Und das muss sein, weil es die Seite ist, die von loginUrl
für Forms Auth identifiziert wird. Kombiniert die Tests, die ich unter den Bearbeitungen 2 und 3 gemacht habe, gewährte ich Zugriff auf eine neue Testseite ( test2.asp
), die nichts Besonderes macht - lädt nur eine statische Seite. Hier ist es:
Und dann habe ich die Protokolldatei überwacht, an die test.asp
angehängt hat, wenn sie ausgeführt wird. Jedes Mal, wenn ich test2
anforderte, erhielt ich einen neuen Eintrag im Log. Jedes Mal, wenn ich eine Seitenanforderung eintrage, läuft test.asp
im Hintergrund (und erhöht die Sitzungsvariable). Hier ist, wie das Protokoll nach drei Anfragen an meine test2
Seite schaute:
test2.asp
macht nichts mit der Sitzungsvariablen (noch Logging), aber es gibt den Beweis. Aus irgendeinem Grund wird in Chrome die Seite loginUrl
mit jeder Anfrage ausgeführt. Ich denke, ich kann das als erwiesen betrachten. Jetzt brauche ich nur eine Lösung!
Mit Hilfe von Fiddler konnte ich das herausfinden.
Es scheint, dass sowohl Chrome als auch Firefox eine zusätzliche Anfrage für Ihr favicon.ico
stellen, unabhängig davon, ob Sie auf Ihrer HTLM-Seite angegeben haben, dass Sie eines verwenden. Der Internet Explorer dagegen stört nicht.
Das war ein Problem für mich aus ein paar Gründen:
favicon.ico
erstellt war Schritt 274. runAllManagedModulesForAllRequests
, also werden Anfragen nach Symbolen, wie alle Inhalte, durch die Formularauthentifizierung ausgeführt. <link>
nicht auf eins festlegen und seinen Standort angeben, versuchen Chrome und Firefox, einen Browser aus Ihrem Webstammordner zu entfernen. Bei der Formularauthentifizierung (und meiner web.config) ist mein root gesperrt. Die einzige Datei, die von meinem root geliefert wird, ist meine loginUrl
Seite. Jedes Mal, wenn eine Anfrage für favicon.ico
gemacht wurde, wurde diese von der Formularauthentifizierung abgelehnt und die Anfrage wurde auf meine loginUrl
Seite umgeleitet, was dazu führte, dass meine loginUrl
Seite zweimal ausgeführt wurde meine Sitzungswerte zu vermasseln. Die folgenden Fiddler Screenshots zeigen den Beweis.
Chrome scheint das Symbol bei jeder Seitenanfrage anzufordern:
Während Firefox es aus irgendeinem Grund anfänglich zweimal anfordert, gibt es dann für nachfolgende Anfragen auf:
Also, die Lösung:
favicon.ico
-Datei und legen Sie sie in Ihrem Webstamm ab. Erlaube anonymen Zugriff darauf über ein <location>
-Element in deinem root web.config
.
Alternativ (wahrscheinlich die bevorzugte Methode, da Sie den Namen und den Ort angeben können):
favicon.ico
-Datei und platzieren Sie sie in einem öffentlichen Unterordner wie /img
. <link>
richtig auf Ihrer loginUrl
Seite.
Tags und Links iis session google-chrome asp-classic forms-authentication