Ich habe kürzlich eine Website entwickelt, die asp.net-Webformulare verwendet, die in proc-Sitzungen verwendet werden, und mir ist aufgefallen, dass die Sitzungs-IDs unter den Browser-Tabs geteilt werden. Ich habe mich gefragt, was Sie für die folgenden Situationen tun würden:
Problem: Mehrere Logins mit verschiedenen Benutzern in einem Browserproblem
Wie warnen Sie den Benutzer in Tab 1, dass der Benutzer sich geändert hat oder wie erzwungen wird, dass sich tab1-Benutzer abmeldet?
Mein erster Gedanke war, eine Liste aktiver Benutzer mit Sitzungs-ID über Datenbank oder Anwendungsobjekt zu führen, aber das Problem, dem ich gegenüberstehe, ist, dass ich die Liste mit Tabs vergleichen werde, wenn ich den HttpContext anfordere .Current.User würde mit "user2" aktualisiert werden. Woher weiß ich, dass Browser Tab 1 ursprünglich für "user1"
war?Schätzen Sie jemanden, der mich über Alternativen oder Best Practices für das oben genannte Problem informiert.
Grüße DotnetShadow
Warum warnen Sie nicht, wenn sich Benutzer2 anmeldet? Mit einer Nachricht wie "Sie sind bereits als Benutzer1 angemeldet, sind Sie sicher, dass Sie sich erneut als ein anderer Benutzer anmelden möchten?"
Einige haben vorgeschlagen, Uniqifier in die URL aufzunehmen und basierend darauf zu tracken.
Wenn Sie das tun, können Sie ASP.Net das auch tun, indem Sie Sitzungen ohne Cookies - es verwendet dann die URL, um die Sitzungs-ID zu enthalten.
Genau so ist es. Du kannst nicht viel dagegen tun. Die Benutzer sind nun an dieses Verhalten gewöhnt, da es bei bekannten Internet-Sites wie Google Mail usw. konsistent ist. Daher sollte es für sie kein großes Problem darstellen.
Alle Registerkarten in einem Browser gehören zur selben Instanz, so dass alle Registerkarten Cookies und Sitzungen teilen. Sie können nicht viel dagegen tun. Wenn Sie dies schlecht implementieren möchten, ist die einzige Lösung, die Ihnen in den Sinn kommt, eine eindeutige Session-ID mit jeder URL zu tragen. Basierend auf dieser eindeutigen ID können Sie einen bestimmten Benutzer verknüpfen. Sie müssen die Sitzungslogik anpassen und sicherstellen, dass alle Links auf Ihrer Website diese eindeutige ID enthalten. Es könnte mit viel Mühe gemacht werden, aber die wirkliche Frage ist, ist es es wert, getan zu werden?
Um dieses Problem zu vermeiden, lege ich umleiten, um eine kurze, zufällige In-URL-Login-ID anzuhängen.
Anstatt die Sitzung direkt zu verwenden, speichere ich dann ein stark typisiertes Objekt in den Sitzungsvariablen unter dem Random-In-URL-Code und verwende das Objekt das für den Sitzungsspeicher. Wenn Sie es einfach halten möchten, könnten Sie ein Wörterbuch verwenden. Zusätzlich zum normalen Sitzungszeitlimit sollten Sie die letzte Verwendung innerhalb jeder Login-ID verfolgen und eine Sitzung manuell beenden, wenn sie zu alt ist, um zu verhindern, dass neue Benutzer alte Logins am Leben erhalten.
Im Wesentlichen entspricht jede ASP.NET-Sitzung einer beliebigen Anzahl von Anmeldesitzungen.
Dies hat die folgenden Vorteile:
Der offensichtliche Nachteil ist, dass Sie den Zufallscode in die URL einfügen müssen; und dass Sie ein bisschen zusätzliche Implementierung benötigen. Sie können den zusätzlichen Code mit einer iframe- und / oder javascript + XHR-basierten Seite verbergen, aber dies ist eine viel invasivere Änderung einer Site. Beachten Sie schließlich, dass Sitzungen ohne Cookies nicht identisch sind. obwohl sie einfacher zu aktivieren sind, beinhalten sie ein wesentlich länger weniger benutzerfreundliches URL-Token und sind durch das Fehlen des normalen Cookie-Session-Tokens auch weniger sicher als Session-Hijacking (da plötzlich jedes andere Programm oder gar jede Maschine das entdeckt Sitzungs-ID kann so tun, als wäre dieser Benutzer).
Tags und Links asp.net session-state