Speichern der Details des angemeldeten Benutzers

Question

Wenn Sie eine Webanwendung erstellen und beispielsweise ein Benutzerobjekt haben, das einen einzelnen Benutzer bezeichnet, wie können Sie Ihrer Meinung nach am besten speichern, dass sich der Benutzer angemeldet hat?

Zwei Möglichkeiten, über die ich nachgedacht habe, waren:

• Die Benutzerdatenbank-ID wird in einer Sitzungsvariablen gespeichert
• Das gesamte Benutzerobjekt wurde in einer Sitzungsvariablen gespeichert

Irgendwelche besseren Vorschläge oder Probleme bei der Verwendung der oben genannten Möglichkeiten?Möglicherweise Sicherheitsprobleme oder Speicherprobleme usw. usw.

Answer 1

Ich empfehle, die ID statt des Objekts zu speichern.Der Nachteil besteht darin, dass Sie jedes Mal auf die Datenbank zugreifen müssen, wenn Sie die Informationen dieses Benutzers abrufen möchten.Sofern auf Ihrer Seite jedoch nicht jede Millisekunde zählt, sollte die Leistung kein Problem darstellen.Hier sind zwei Vorteile:

1. Wenn sich die Informationen des Benutzers irgendwie ändern, werden in Ihrer Sitzung keine veralteten Informationen gespeichert.Wenn einem Benutzer beispielsweise von einem Administrator zusätzliche Berechtigungen gewährt werden, stehen diese sofort zur Verfügung, ohne dass sich der Benutzer ab- und wieder anmelden muss.

2. Wenn Ihre Sitzungsinformationen auf der Festplatte gespeichert sind, können Sie nur serialisierbare Daten speichern.Wenn Ihr Benutzerobjekt also jemals etwas wie eine Datenbankverbindung, einen offenen Socket, einen Dateideskriptor usw. enthält, wird dies nicht ordnungsgemäß gespeichert und möglicherweise auch nicht ordnungsgemäß bereinigt.

In den meisten Fällen stellen diese Bedenken kein Problem dar und beide Vorgehensweisen wären in Ordnung.

Answer 2

Aus Sicherheitsgründen würde ich eine Sitzungs-ID generieren (entweder eine GUID oder einen kryptografisch sicheren RNG) und eine Tabelle haben, die nur Sitzungs-IDs den Benutzer-IDs zuordnet.Dann speichern Sie einfach die Sitzungs-ID in ihren Cookies und lassen sie als Proxy für die Benutzer-ID fungieren.

|Session |UserID |
|--------+-------|
|a1d4e...+ 12345 |
|--------+-------|
|c64b2...+ 23456 |
|--------+-------|

Damit kann sich niemand durch Erraten seiner ID als ein anderer Benutzer ausgeben.Außerdem können Sie damit die Sitzungen der Benutzer begrenzen, sodass sie sich von Zeit zu Zeit anmelden müssen (üblich sind zwei Wochen).Und wenn Sie weitere Daten zu ihrer Sitzung speichern möchten, können Sie diese einfach zu dieser Tabelle hinzufügen.

Answer 3

Denken Sie daran, dass, wenn Sie alle Attribute des Benutzers (einschließlich Berechtigungen) in der Sitzung speichern, alle Änderungen am Benutzer erst wirksam werden, wenn er sich erneut anmeldet.

Persönlich speichere ich den Namen und die ID zum schnellen Nachschlagen und rufe den Rest bei Bedarf ab.

Answer 4

Die Speicherung der ID ist in den meisten Fällen die beste Vorgehensweise.Ein wichtiger Grund dafür ist die Skalierbarkeit.Wenn Sie das Benutzerobjekt (oder beliebige Entitäten aus der Datenbank, statt nur deren IDs) speichern, werden Sie auf Probleme stoßen, die Anzahl der Server zu erhöhen, die Ihre Site bedienen.Für weitere Informationen googeln Sie nach „Shared Nothing Architecture“.

Answer 5

Ich denke, dass es davon abhängt, welche Plattform Sie verwenden.Wenn Sie ASP.net verwenden, würde ich mir das auf jeden Fall ansehen FormsAuthentication Klasse und alle dort integrierten (und erweiterbaren) Funktionen, die Sie zum Speichern Ihrer angemeldeten Benutzereinstellungen verwenden können.

Answer 6

Ich würde einen Hash-Wert der Benutzer-ID und der Sitzungs-ID speichern und diesen dann in einer Sitzungstabelle in der Datenbank abgleichen.Auf diese Weise wird es schwieriger, die Sitzungsdaten zu fälschen.Könnte ich zur zusätzlichen Kontrolle auch die IP überprüfen?

Ich bin mir nicht sicher, ob ich mich darauf verlassen möchte, dass eine Benutzer-ID in einer Sitzungsvariablen gespeichert wird, und darauf vertrauen möchte, dass es sich um diesen Benutzer handelt, da er relativ einfach geändert werden kann und als anderes Mitglied Zugriff erhält

Answer 7

Normalerweise speichere ich den Benutzer in der Sitzung.Das Problem, dass Änderungen erst nach der Anmeldung möglich sind, kann gelöst werden, indem das Objekt in der Sitzung durch eine neue Kopie ersetzt wird, nachdem Sie Änderungen vorgenommen haben.

Answer 8

Unser Benutzerobjekt ist ziemlich leichtgewichtig, daher haben wir uns dafür entschieden, es in einer Sitzungsvariablen zu speichern.Ich bin mir nicht sicher, ob das am effizientesten ist, aber bisher funktioniert es sehr gut.