Se un repository o il servizio Login / Register hanno un servizio di crittografia come dipendenza?

Question

Se un repository o il servizio Login / Register hanno un servizio di crittografia come dipendenza?

#1 da (1 voti)
#2 da (1 voti)
#3 da (1 voti)

1

Sto progettando un semplice login utente / programma di registrazione con login / registro utente e un repository. Le password per gli utenti devono essere crittografate quando sono archiviate, ma non so dove mettere il passaggio di crittografia sul repository o nel servizio che gestisce la logica per la registrazione / login in un utente. le password degli utenti dovrebbero sempre essere crittografate e per questo motivo penso che sia meglio avere questa logica nel repository dato che è la classe che verrà chiamata ogni volta che voglio fare qualcosa con un utente. Mettere la logica di crittografia sul servizio significa che ogni servizio che vuole fare qualcosa con un utente deve essere consapevole della logica di crittografia.

Dall'altro lato, non so se il repository dovrebbe essere a conoscenza di questa logica.

O forse vale la pena creare un oggetto valore "UserPassword" che riceve la password grezza e una cifra come parametri del costruttore e salva immediatamente la password crittografata per il recupero futuro?

Sto provando a progettare un'architettura esagonale. (Non so se questo può aiutare)

design architecture

posta vicaba 26.04.2016 - 13:00

fonte

3 risposte

1

L'implementazione di hashing così difficile nella lingua / framework che usi, in modo tale da giustificare un servizio dedicato separato?

Ciò che intendo è che, ad esempio, in Python, sono solo tre righe di codice . In C #, sembra molto più complicato , ma ancora non abbastanza la mia opinione di avere un servizio separato per questo. Un'interfaccia, una classe di implementazione, uno o più stub / mock e tutta la logica di dipendenza delle dipendenze sembra un eccesso per una semplice attività.

Quando si tratta di test di unità, eliminare questa dipendenza specifica incorporando l'hashing direttamente nella classe che gestisce l'utente non sembra neanche assurdo. I test unitari dovranno confrontare la password di output non con quella grezza dallo stub, ma con un hash specifico. Questo non è difficile, dal momento che puoi comunque generare un hash con facilità (e farlo con un linguaggio diverso ti aiuta ad assicurarti che il tuo codice sia effettivamente corretto).

Potrebbe avere senso avere un servizio separato in una situazione in cui è necessario scambiare regolarmente le implementazioni di hashing. Non ho mai lavorato a un progetto che avrebbe richiesto questo.

A parte questo caso specifico, un servizio dedicato è eccessivo. Non sovrascrivere il tuo codice.

risposta data 26.04.2016 - 19:16

fonte

1

Il tuo livello aziendale è il luogo in cui deve avvenire la crittografia. I repository dovrebbero riguardare solo il recupero e l'archiviazione dei dati.

risposta data 26.04.2016 - 20:16

fonte

Leggi altre domande sui tag design architecture

Perché l'eccezione HttpClientErrorException di Spring è un'eccezione non controllata? Archiviazione dei dati per semestre

score 1 · Accepted Answer

Generalmente i repository non dovrebbero essere coinvolti nella crittografia a meno che non si tratti di una caratteristica del livello di persistenza, quindi a meno che tu non stia chiedendo a il database di fare crittografia / hashing o usando alcune query molto interessanti, io utilizzare un servizio separato.

Si divide la responsabilità. Creare un servizio e, se necessario, iniettare il Servizio in il Repository come dipendenza. Come bonus, questo rende più facile assicurarsi che le informazioni sensibili (ad esempio chiavi di crittografia o sali globali) vadano solo in un posto e non perdano in altre aree dell'applicazione.