Ist es besser, Benutzerdaten in einer Datenbank als in Cookies zu speichern?

Question

Warum speichern wir nicht die Cookie-Informationen von Website-Besuchern (Abonnenten) in der Datenbank, anstatt eine Datei auf dem Computer des Benutzers zu setzen. Ja, ich weiß, ich könnte aus folgenden Gründen albern klingen:

1. Pflege von Datenbankinformationen für jeden einzelnen Benutzer immer kleine ‚Klumpen‘ von Daten ist schwierig.

2. Es kann schwierig sein, Daten abzurufen, wenn der Datenbankserver inaktiv ist.

3. Kontinuierliche Anfragen sind für jede kleine Information an den Webserver zu richten.

Mein Punkt ist, wenn wir die Daten des Benutzers in einer Datenbank und nicht in einer Datei auf der Client-Rechner speichern gehen, wir Sicherheit für die Kunden zur Verfügung stellen können durch keine andere Organisationen oder andere Websites ermöglichen (oder Hacker), um von den Cookies auf die Benutzerinformationen zuzugreifen.

Darüber hinaus können wir die Aktivitäten oder das Verhalten des Benutzers verfolgen. (Ich meine, wir wissen tatsächlich nicht, was der Benutzer tut (clientseitige Aktivität) wie Datenverfälschung.)

Wenn Sie das Gefühl haben, dass es schwierig sein kann, ständig Anfragen an den Webserver zu senden, ist es nicht Danke an Ajax. Dies gibt meiner Position eine gewisse Unterstützung: das Senden von Anfragen an einen Webserver, der mit Ajax so einfach gemacht wurde.

Also ist es eine gute Idee, sensible Informationen des Benutzers in einer Datenbank zu speichern, anstatt eine kleine Datei auf dem Computer des Benutzers zu setzen?

Um genau zu sein, rede ich nicht über Sitzungen!

Answer 1

Ihr Ansatz ist definitiv gültig, hat aber ein grundlegendes Problem (was wahrscheinlich der Grund dafür ist, warum Cookies überhaupt erstellt wurden): Identifizierung.

Wie können Sie Benutzer A und Benutzer B identifizieren, ohne nach einem Benutzernamen/Passwort zu fragen? Cookies bieten eine einfache Möglichkeit, diese Unterscheidung zu treffen. Sobald der Benutzer identifiziert ist, werden Ihre Punkte vollständig gültig.

Im Allgemeinen sind vertrauliche Informationen nicht dazu gedacht, in Cookies gespeichert zu werden.Solche Informationen werden am besten auf der Serverseite gespeichert (wie Sie angegeben haben).

Answer 2

Sensible Informationen sollten nicht in einem Cookie enthalten sein, da stimme ich Ihnen zu. Es sollte irgendwo serverseitig entweder in einer flachen Datei auf dem Server selbst oder in einer Datenbank gespeichert werden.

Was Sie auf dem Client-Rechner benötigen, ist ein kleiner Cookie, der einen obskuren, schwer zu erratenden Verweis auf diese sensiblen Daten enthält.

Herzlichen Glückwunsch! Du hast gerade Sessions neu erfunden!

(Webserver auf dem Server statt in flachen Dateien in einer Datenbank Sitzungsdaten zu speichern, eingerichtet werden, wenn Sie es vorziehen, auf diese Weise.)

Answer 3

verwenden wir Cookies Allgemeinen, weil wir unbedingt keine sensiblen Einstellung Daten in ihnen. Wenn Ihre Anwendung sensible Daten enthält, mit denen Sie nicht herumhantieren wollen, dann verwenden Sie alle Server- und DB-Tools, die Ihnen zur Verfügung stehen, um dies zu lösen, aber nicht alle Anwendungen und Implementierungen benötigen diese Sicherheitsstufe in dieser Hinsicht. Das Setzen von Cookies ist für die Bequemlichkeit, das ist alles.

Answer 4

Dies ist bereits geschehen, oder wir speichern Benutzernamen, Adressen und Kreditkarteninformationen in einem Cookie und nicht in der Datenbank. Sie müssen herausfinden, was sinnvoll ist, um in der Datenbank zu bleiben, was sinnvoll ist, um sie als Cookie zu speichern. Serverleistung, Bandbreite, Skalierbarkeit - all dies muss berücksichtigt werden. Denken Sie daran, je mehr wir Server-Seite speichern, desto mehr müssen wir Client-Seite liefern.

Sie erwähnen auch Sitzungen - Sitzungen sind Cookies (irgendwie).

Answer 5

Ich stieß auf diesen Beitrag bei der Suche nach einem ähnlichen Ratschlag in Bezug auf das Cookie vs Datenbank-Argument.

Angenommen, ich habe einige Benutzerdaten in Form von Integer-Listen, d. H. Einige mit Lesezeichen versehene Produkte, maximal 80 pro Benutzer.

In der Datenbank könnte dies in 4 Tabellen (1 für jeden Datentyp) transponieren, also 20 Zeilen pro Benutzer.

Wenn Sie eine Million Unique Visitors pro Jahr hätten und aus Gründen des Arguments 70% Gastbenutzer im Gegensatz zu Membern wären, könnte dies 14m Zeilen zu einer Tabelle hinzufügen, die ansonsten nur 6m Zeilen lang wäre. Natürlich könnten Sie eine Ausnahmeregelung für Gastbenutzer haben, aber das wird schwierig zu verwalten - was zu sagen ist, dass ein Benutzer nicht nach 9 Monaten zurückkehrt, um seine Daten gelöscht zu finden.

Die andere Seite der Medaille ist, dass Gäste Daten in Cookies gespeichert werden, so ist es egal, wie lange es gespeichert ist. Ich schätze, dass mehr Arbeit mit der Verwaltung von zwei Speichermethoden verbunden ist, aber das ist der einzige Nachteil, den ich mir vorstellen kann.

Jeder hat irgendwelche Ansichten dazu, wie ich einen Ratschlag schätzen würde.

Answer 6

Es stimmt, dass die gängige Meinung ist, die Verwendung von Cookies für sensible Daten zu vermeiden, da diese auf dem Client gespeichert sind und ein Hacker mit ihnen basteln und möglicherweise Schaden anrichten kann. Es gibt jedoch einen zwingenden Grund, warum Cookies einen zweiten Blick wert sind: Skalierbarkeit. Es ist schwierig, einen hochleistungsfähigen Pool von Sitzungsdaten zur Verfügung zu einer beliebigen Anzahl von Cloud-Server haben:

http://aws.typepad.com/aws/2012/04/scalable-session-handling-in-php-using-amazon-dynamodb.html

Hier ist ein Link fand ich, die, wie ein sicheres Cookie System sehr ins Detail geht könnte gebaut werden:

http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf

So könnte es sein, dass alte, was wieder neu.