ASP.NET_SessionId fehlt

Ich verliere die ASP.NET_SessionId beim Wechsel zwischen den Seiten auf meine Website. Das Problem tritt bei Chrome/Firefox/Safari. Es geschieht nicht im IE. Es ist ziemlich seltsam...hier ist mein Szenario.

Meine Website zugegriffen werden kann, durch Eingabe von www.example.org oder example.org im browser (dies ist eine wichtige Information, wie Sie sehen werden).

Ich eingeben example.org. Von meiner Homepage, ich logge in meine Website (Hinweis: ich bin nicht mit ASP.NET forms-Authentifizierung). Ich bin an meinem Standard-Benutzer-Seite (z.B. Benutzerseite.aspx). Von dieser Seite habe ich klicken Sie auf ein <a> schickt mich zu einer anderen Seite auf meiner Website. Die <a> link ist voll-qualifiziert (z.B., http://www.example.org/page2.aspx). Wenn ich geschickt bekommen auf der neuen Seite meine session verloren!!!

So, ich lief Fiddler ' zu versuchen, und entdecken Sie das problem. Was ich fand, war interessant. Die Anfrage-Header-tag Referer war verloren zwischen den Seiten.

Hier sind die Schritte:

  1. Gehen example.org.
  2. Login example.org.
  3. Ich bekommen umgeleitet zu Benutzerseite.aspx. Der Referer ist http://example.org. Die ASP.NET_SessionId gesetzt.
  4. Ich auf die <a> (z.B., http://www.example.org/page2.aspx). Nachdem die Seite gerendert wird, wird die ASP.NET_SessionId verloren.

Den verlorenen ASP.NET_SessionId verloren geht, konsequent ist Google Chrome/Firefox/Safari. Dies geschieht nicht im IE.

Wenn Sie die obigen Schritte wiederholen, durch die Substitution example.org mit www.example.org die ASP.NET_SessionId ist nicht verloren. Es funktioniert, richtig jedes mal.

Irgendwelche Gedanken zu diesem Verhalten?

  • in fiddler wird der cookie gesendet, die in allen Fällen oder nicht?
  • was Sie versuchen, in page2 code hinter? und sind Sie mit InProc-session-state-Modus?
InformationsquelleAutor Steve | 2012-04-04
  1. 6

    Fügen Sie diese auf Ihrer Website.config unter den <system.web - > - element

    <httpCookies domain=".mysite.com" />

    Sehen, ob es irgendeine änderung im Verhalten. Es klingt, als ob sub-domains Versagen, obwohl ich dachte, das cookie wurde basierend auf der root-domain, um mit zu beginnen. dieser sollte Kraft es so.

    • Ich denke, man kann auf etwas. Der cookie ist nur die eine Seite der Gleichung auf die session-state-management. Es gibt auch die server. Ich glaube, dass aus Sicht der IIS http://www.mysite.com eine andere Anwendung ist als nur mysite.com. Auch wenn Sie auf demselben physischen Dateien/Verzeichnissen, Sie sind getrennte Einheiten, und die Sitzung wird basierend auf httpcontext.aktuelle, die mit der aktuellen Anwendung Anwendungsbereich. (Ich hoffe, jemand schlauer als ich kann Wort, das besser und zu überprüfen, ob ich Recht habe auf das. Ich bin wohl auch nicht. Ich bin eigentlich nur darum, dass aus und hofft, zu lernen.)
    • Sie alle existieren in der gleichen app-pool. Alle konfigurierten host-Header wird auf der gleichen app-pool. Ich diesem Fall ich denke, der browser ist einfach nicht das versenden der cookie über, da der cookie-domain (also Ihre Arbeit wie vorgesehen) Die wichtige Sache, hier (und nicht bereits in der OP) ist, wenn fiddler zeigt der cookie gesendet werden über oder nicht.
    • Adam, dein Vorschlag hat funktioniert. Danke!
    InformationsquelleAutor Adam Tuliper - MSFT
  2. 1

    In meinem Fall Folgendes war das Problem:

    In meinem lokalen Visual Studio-Umgebung, die meine Entwicklung "web.config" - Datei versehentlich geändert werden enthalten die folgenden:

    <configuration>
    <system.web>
        <httpCookies requireSSL="true" />
    </system.web>
</configuration>

    Seit der Entwicklung IIS Express läuft bei http://localhost:7561, die nicht HTTPS, ist diese Prüfung ausgelöst, um nicht eingestellt/akzeptiert keine cookies, einschließlich der session-ID-cookie.

    Lösung war zu einfach kommentieren Sie die <httpCookies requireSSL="true" /> Linie.

    Einer anderen, ähnlichen Frage, die ich mir vorstellen könnte ist, dass die Content-Security-Policy HTML-meta-tag, dass auch steuert, wie cookies behandelt werden, könnte auch so konfiguriert werden nicht zulassen, dass die session-ID-cookie gesetzt werden.

    InformationsquelleAutor Uwe Keim
Schreibe einen Kommentar