Entity Aktualisierung Strategie

Question

Es gibt einige Diskussionen über meinem Team über Entitätsdaten Aktualisierung und wie sie am besten zu nähern. Dies ist ein Framework, Sicherheit und so sind hier einige der Einschränkungen und Ideen.

1. jede Tabelle in DB eine PK hat, die eine GUID ist, ist dies für unsere Multi-Node-Clustering-Lösung erforderlich. Die Idee ist, dass wir das nicht über eine API an einen Kunden für eine Entität verfügbar machen möchten, weil es zwei Dinge tun konnte,
   1. gibt ihnen weitere Informationen, die für ihre Arbeit benötigt und Hacker mehr Informationen über das System zu geben.
   2. Unterstützung Alptraum ist, dass ein Client Hardcodes auf diese ID in irgendeiner Art und Weise, und wenn wir brauchen, um unsere PK-Kunden zu ändern, ist betroffen.

Lösungen sind die natual Schlüssel der Elemente wie Role-Objekt mit einem eindeutigen Namen zu belichten, und Realm zusammen guarentee Einzigartigkeit jedoch die Aktualisierung einer dieser Werte ist die Herausforderung, weil Sie die alten und neuen Werte angeben müssen aktualisiert werden, oder passieren zwei Objekte in ursprünglichem und neuen Objekt, so können wir den einen aktualisieren finden. Art chaotisch,

Ein weiterer Ansatz ist es, einen alternativen Schlüssel zu machen und diese an den Kunden ausgesetzt haben, können sie alles wollen sie nutzen und wir kümmern uns nicht weil es nicht unseren PK gebunden ist.

es scheint, dass jeder in diesen Tagen nur PK als ID verwendet für Unternehmen ohne Probleme, nicht sicher, wie unser Team von veterns aus den alten timey Programmierung Tagen zu überzeugen.

Ein weiteres Problem ist, wie teilweise Updates zu unterstützen, Problem ist, dass Sie Unternehmen mit 10 Eigenschaften, 4 Sammlungen, etc ... mit einem Namen + Reich-Combo und angeben, welche Eigenschaft zu aktualisieren, anstatt ganzem Objekt ändert 1 Feld nach unten ziehen , zurückschicken für Updates. Ich sage faul Last der Sammlungen, aber nicht sicher, ob teilweise Aktualisierung sinnvoll ist.

Gedanken?

Danke!

Answer 1

Mein Ansatz für einen Sicherheitsrahmen so sein würde:

• Geben Sie etwas in der Datenbank eine interne ID (Identitätsspalte, Reihenfolge, was auch immer Ihre Datenbank-Unterstützung. In Hibernate "native id-Spalte erzeugt" sprechen). Schließlich wirst du es brauchen und zu Nachrüstung ist eine Menge Arbeit.

• Wenn Sie eine ID für den Benutzer zur Hand benötigen, erzeugt eine Zufallszahl, überprüfen Sie, dass es schon nicht benutzt wurde, verbinden Sie es mit einer internen ID und es dann den Benutzer übergeben. Nie auszuteilen die interne ID und nie Verwendung IDs, die von Crackern erraten werden kann.

Wie bei Teil-Updates, beginnen sie nur dann Sinn zu machen, wenn Sie viele Objekte mit vielen Attributen haben. Für 10 Attribute, würde ich " vorzeitige Optimierung " sagen.

Answer 2

natürliche Schlüssel verwenden, wenn Sie ID Client aussetzen müssen. Es ist nicht so einfach zu implementieren, aber das ist der richtige Weg.

Könnten Sie etwas mehr Details über dieses Teil-Updates zur Verfügung stellen? Ich habe es nicht. : /

Answer 3

Mit GUIDs auf jedem Tisch als ein Primärschlüssel wie nach Ärger klingt. Ich habe diesen Ansatz nicht überall hin mitgenommen gesehen, wenn ich dir wirklich bin Missverständnis. Warum Ausgabe nicht nur eine UID für jeden Benutzer und die Arbeit mit der UID?

Dieser Ansatz ist am häufigsten in allen Unternehmen. Die UID ist nicht PII , so dass Sie in Ordnung sind rechtlich als wie von einer sicherheitstechnischen Sicht war.