Gespeicherte Benutzerdetails speichern

Ich empfehle, die ID und nicht das Objekt zu speichern. Der Nachteil ist, dass Sie die Datenbank jedes Mal treffen müssen, wenn Sie die Informationen dieses Benutzers erhalten möchten. Wenn jedoch nicht jede Millisekunde auf Ihrer Seite zählt, sollte die Leistung kein Problem darstellen. Hier sind zwei Vorteile:

1. Wenn sich die Benutzerinformationen irgendwie ändern, werden Sie in Ihrer Sitzung keine veralteten Informationen speichern. Wenn einem Benutzer z. B. zusätzliche Berechtigungen von einem Administrator erteilt werden, sind diese sofort verfügbar, ohne dass der Benutzer sich abmelden und erneut anmelden muss.

2. Wenn Ihre Sitzungsinformationen auf der Festplatte gespeichert sind, können Sie nur serialisierbare Daten speichern. Also, wenn Ihr Benutzerobjekt jemals etwas wie eine Datenbankverbindung enthält, öffnen Sie den Socket, den Dateideskriptor usw., dann wird dies nicht richtig gespeichert und kann auch nicht richtig bereinigt werden.

In den meisten Fällen werden diese Bedenken kein Problem darstellen, und beide Ansätze wären in Ordnung.

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

  

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

Damit kann niemand einen anderen Benutzer annehmen, indem er seine ID rät. Außerdem können Sie die Sitzungen der Benutzer begrenzen, sodass sie sich immer wieder anmelden müssen (zwei Wochen sind üblich). Und wenn Sie andere Daten über ihre Sitzung speichern möchten, können Sie sie einfach zu dieser Tabelle hinzufügen.

Denken Sie daran, dass alle Benutzerattribute (dies gilt auch für Berechtigungen) in der Sitzung gespeichert werden. Änderungen am Benutzer werden erst wirksam, wenn sie sich erneut anmelden.

Persönlich speichere ich den Namen und die ID zur schnellen Bezugnahme und hole den Rest, wenn es nötig ist.

Ich denke, dass es davon abhängt, welche Plattform Sie verwenden. Wenn Sie ASP.net verwenden, würde ich definitiv die FormsAuthentication betrachten Klasse und alle darin integrierten (und erweiterbaren) Funktionen, mit denen Sie Ihre eingeloggten Benutzereinstellungen speichern können.

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, treten Probleme auf, wenn Sie die Anzahl der Server für Ihre Site erweitern. Weitere Informationen finden Sie unter "Shared Nothing Architecture".

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

Ich bin mir nicht sicher, dass ich mich darauf verlassen sollte, dass eine Benutzer-ID in einer Sitzungsvariablen gespeichert ist, und vertraue darauf, dass es dieser Benutzer war, da er relativ leicht geändert werden und als ein anderes Mitglied Zugriff erhalten könnte     

Ich speichere den Benutzer normalerweise in der Sitzung. Das Problem kann nicht geändert werden, bis die Anmeldung abgeschlossen ist, kann gelöst werden, indem das Objekt in der Sitzung nach einer Änderung durch eine neue Kopie ersetzt wird.

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