2016-10-27 1 views
2

Wenn ich mit klassischem ASP.NET oder sogar mit alten Webformularen gearbeitet habe, war die HttpContext.Current.Session benutzerspezifisch. Wenn der Benutzer die Anfrage stellt, erhält er den Sitzungscookie und dann weiter, dass diese Sitzung nur diesem Benutzer gehört. So können zwei verschiedene Benutzer den Sitzungsschlüssel mit demselben Namen in ihrer jeweiligen Sitzung haben.Ist die Kernsitzung von ASP.net nicht benutzerspezifisch?

Ich lese die Dokumentation auf Sitzung in ASP.NET Core und sieht aus wie es das gleiche Konzept wie alte asp.net hat, jedoch einige Hinweise in der Dokumentation ist verwirrend.
here es sagt

Session Speicherung auf einer Cookie-basierte Kennung beruht auf Daten zuzugreifen auf eine bestimmten Browser-Sitzung im Zusammenhang (eine Reihe von Anfragen von einem bestimmten Browser und Maschine). Sie können nicht unbedingt davon ausgehen, dass eine Sitzung auf einen einzelnen Benutzer beschränkt ist. Seien Sie also vorsichtig, welche Art von Informationen Sie in Session speichern. Es ist ein guter Ort, Anwendungszustand zu speichern, die zu einer bestimmten Sitzung spezifisch ist, die aber braucht nicht permanent

auch beibehalten werden here es sagt

Session nicht hemmend ist, Wenn also zwei Anfragen versuchen, den Inhalt der Sitzung zu ändern, gewinnt der letzte. Des Weiteren ist die Sitzung als zusammenhängende Sitzung implementiert, was bedeutet, dass alle Inhalte zusammen gespeichert werden. Dies bedeutet, dass, wenn zwei Anforderungen verschiedene Teile der Sitzung (verschiedene Schlüssel) ändern, können sie immer noch gegenseitig beeinflussen.

können so sagen, ich habe Benutzer1 angemeldet und auf eine Aktion gesetzt i

`Session.SetInt32("key1", 123)` 

jetzt User2 loggt von einem anderen Gerät in und auf eine Aktion gesetzt i

`Session.SetInt32("key1", 999)` 

Frage 1
Wird der Schlüssel von User1 überschrieben?

Beachten Sie auch here sagt

ASP.NET Schiffe mit mehreren Implementierungen von IDistributedCache, mit einer In-Memory-Option (nur während der Entwicklung und Tests verwendet werden)

Frage 2
Was ist die andere Implementierung von IDistributedCache, die ich in der Produktion verwenden kann?

Antwort

2

# 1

Session ist nicht an einen Benutzer gebunden, weil Sitzung nur identifiziert wird, indem sie Sitzungsschlüssel ist, also wenn jemand den Besitz des Sitzungsschlüssel/Cookie bekommt er es zugreifen kann.

Asp.Net Core Identity hat einen eigenen Cookie (wenn Sie Cookie-Authentifizierung verwenden) und Session-Middleware verwenden auch einen eigenen Cookie.

Natürlich können Sie auch Sitzungen ohne einen Benutzer verwenden. Nehmen Sie zum Beispiel Google.com. Wenn Sie Google das erste Mal besuchen, werden Ihnen Richtlinien angezeigt und ein Sitzungscookie festgelegt. Alle Einstellungen, die Sie vornehmen (z. B. Fälligkeitsfilter), werden in der Sitzung gespeichert, auf die bei jeder Suche zugegriffen wird.

Dies alles ohne eingeloggt zu sein, so dass es überhaupt keinen Benutzer gibt.

# 2

Open Source ist dein Freund: https://github.com/aspnet/Caching/tree/dev/src

Redis und SqlServer die Standard verteilten Caches sind, mit InMemory nur für Entwicklung/Single-Node ist. Es kann auch andere Bibliotheken von Drittanbietern geben, die Unterstützung hinzufügen.

+0

für # 1, wie das ist anders als klassische asp.net? Session in klassischen asp.net funktioniert genauso, wie ich denke. Auch wenn Sitzung nicht empfohlen wird dann, welche Option habe ich zum Speichern von benutzerspezifischen Daten – LP13

+0

Ich habe nicht gesagt, es ist nicht zu empfehlen, hängt davon ab, wo Sie es verwenden (in WebAPI seine ziemlich schlechte Idee als WebAPI/REST-Service sollte stateless) Für MVC ist es ziemlich gut, es zu benutzen. Wenn Sie es an einen Benutzer binden möchten, speichern Sie die Benutzer-ID und ip darin, vergleichen Sie es bei jeder Anfrage (dh schreiben Sie eine Middleware, die es überprüft und falls erforderlich die Sitzung ungültig macht, wenn Benutzer und gespeicherte Benutzer-ID nicht übereinstimmen) – Tseng

+0

Es ist nicht anders als klassisch, aber Leute und besonders nervige Sicherheits-Scan-Tools gehen manchmal davon aus, dass die Sitzung mit einem Benutzer verknüpft ist, also sagen wir es aus, um klar zu sein. – blowdart

4

Für Frage 1.

Kein, ein Benutzer einen Sitzungsschlüssel modifiziert wird nicht ein anderer Benutzer zu Schlüsseln überschreibt. Die Sitzung ist für jeden Besucher/Benutzer aufgrund des erstellten .AspNetCore.Session-Cookies eindeutig.

Alle Session.Set-Aufrufe werden für diesen eindeutigen Bezeichner gespeichert.

Verwandte Themen