strategia di aggiornamento Entity

Question

V'è una certa discussione sul mio team sull'aggiornamento dei dati di entità e il modo migliore per avvicinarsi. Si tratta di un framework di sicurezza e quindi ecco alcuni dei vincoli e delle idee.

1. ogni tavolo nel DB ha un PK che è un GUID, questo è richiesto per la nostra soluzione di clustering multi-nodo. L'idea è che non vogliamo esporre questo su un soggetto a un cliente tramite un API perché potrebbe fare due cose,
   1. dare loro ulteriori informazioni che aveva bisogno per il loro lavoro e dare hacker maggiori informazioni sul sistema.
   2. Supporto incubo è che un client hardcodes a questo ID in qualche modo e se abbiamo bisogno di cambiare i clienti del nostro PK sono influenzati.

Le soluzioni sono per esporre la chiave natuale degli oggetti come oggetto Role con un nome univoco, e Realm, insieme guarentee unicità comunque aggiornando uno di questi valori è la sfida, perché è necessario specificare i vecchi e nuovi valori per aggiornare, o passare due oggetti in oggetto originale e nuovo, in modo che possiamo trovare quello da aggiornare. sorta di disordinato,

Un altro approccio è quello di rendere una chiave alternativa e hanno questo esposto al cliente di poter utilizzare tutto quello che vogliono e non ci interessa perche 'non è legato al nostro PK.

sembra che tutti questi giorni proprio utilizza PK come ID per le entità senza problemi, non so come convincere il nostro team di veterns dei vecchi tempi di programmazione star seduto.

Un altro problema è come sostenere gli aggiornamenti parziali, problema è che avete ente con 10 immobili, 4 collezioni, ecc ... con un nome + regno combo e specificare quale proprietà per aggiornare invece di tirare giù tutto il cambiamento oggetto 1 campo , rispedire per l'aggiornamento. Io dico di carico pigri le collezioni, ma non sono sicuro se aggiornamento parziale ha un senso.

pensieri?

grazie!

Answer 1

Il mio approccio per un quadro di sicurezza sarebbe come questo:

• Dare nulla nel database di un ID interno (colonna di identità, di sequenza, qualunque sia il vostro supporto di database. "Nativo generato colonna id" in Hibernate dire). Alla fine, si sta andando ad avere bisogno e di retro-fit è un sacco di lavoro.

• Se avete bisogno a portata di mano un ID per l'utente, generare un numero casuale, controllare che non sia stato già utilizzato, collegarlo a un ID interno e poi consegnarlo all'utente. Mai distribuire l'ID interno e non ID uso che possono essere indovinati dai cracker.

Per quanto riguarda gli aggiornamenti parziali, cominciano solo a dare un senso se hai un sacco di oggetti con un sacco di attributi. Per 10 attributi, direi " prematura ottimizzazione ."

Answer 2

Con il tasto naturale se è necessario esporre id al cliente. Non è così facile da implementare, ma questo è il modo corretto.

Potrebbe fornire po 'di più dettagli su tali aggiornamenti parziali? Non ho capito. : /

Answer 3

Utilizzando GUID su ogni tavolo come chiave primaria suona come in cerca di guai. Non ho visto questo approccio adottato da nessuna parte a meno che non sto davvero equivoco. Perché non solo emettere un UID per ogni utente e di lavoro con l'UID?

Questo approccio è più comune in tutte le aziende. L'UID non è PII in modo che siano a posto legalmente come era da un punto di vista della sicurezza.