Dove e come gestire l'hashing della password utente in Clean Architecture?

Question

Dove e come gestire l'hashing della password utente in Clean Architecture?

#1 da (2 voti)

1

Attualmente sto costruendo una nuova applicazione e sto provando ad applicare alcuni dei principi di Pulisci architettura . Uno dei miei primi roadblock sta implementando il mio sistema Identity (per evitare di essere strettamente associato alla libreria AspNetCore.Identity .

Una delle mie preoccupazioni è l'hashing della password e la generazione. Sto osservando un processo simile o simile al AspNetCore. Identity Password Hasher , ma non sono abbastanza sicuro di dove dovrei gestire questa logica.

Il mio pensiero iniziale è che si tratta delle mie entità di dominio, dovrei inserirle nel mio livello Domain . Tuttavia, sono preoccupato che questo creerà mal di testa e logica sparsa in futuro mentre convalido le password. D'altra parte, potrei definire la mia interfaccia IPasswordHasher nel mio livello applicativo, ma questo ha la conseguenza negativa del mio strato applicativo che regola il mio schema di hashing e di convalida. Nel caso in cui condivido queste entità con un'altra applicazione in futuro, dovrei assicurarmi che l'algoritmo di hashing sia lo stesso.

Ma con lo stesso token, sarebbe bello usare semplicemente l'interfaccia IPasswordHasher che è già definita in Microsoft.AspNetCore.Identity , ma non voglio avere quell'accoppiamento stretto.

Quindi quale sarebbe l'approccio ideale per implementare una sorta di logica di hashing (potenzialmente anche solo usando il PasswordHasher definito in AspNetCore) senza dover fare riferimento alla libreria AspNetCore nei miei livelli di applicazione / dominio? E dove dovrei effettivamente implementare l'hashing della password, al livello dominio o al livello applicazione?

c# architecture design-patterns hashing architectural-patterns

posta JD Davis 23.11.2018 - 21:11

fonte

1 risposta

Leggi altre domande sui tag c# architecture design-patterns hashing architectural-patterns

Posso usare Entity Framework con un livello API SOAP su un database? UML che estende le assenzioni di classe con generalizzazioni

score 2 · Answer 1

La gestione dell'identità probabilmente non fa parte del dominio del tuo problema principale, quindi non ha alcun posto nella tua logica aziendale principale. Inoltre, le entità (il centro nell'architettura pulita) non dovrebbero dipendere da sistemi esterni come database o possibilmente sistemi di gestione delle identità specifici. Invece, si definisce un'interfaccia per i servizi richiesti dal core e quindi si implementa quel servizio. Questa implementazione si troverebbe su un livello simile a un "livello applicazione", ma si noti che l'architettura pulita in particolare non ha livelli up-down, solo livelli inside-out. Le parti interne definiscono le interfacce implementate all'esterno.

Dal punto di vista del dominio del problema principale, l'esatto schema di gestione delle identità e l'algoritmo di hashing della password sono davvero irrilevanti. È quindi corretto che questi dettagli siano decisi da un servizio esterno. Ovviamente il servizio potrebbe essere implementato in modo errato (ad esempio la memorizzazione di password in chiaro), ma così potrebbe essere qualsiasi gestione dell'identità all'interno delle entità. Ma esattamente questa possibilità che le cose vadano storte implica anche una flessibilità che può essere utilizzata per far andare rapidamente i test. Gli algoritmi di hashing della password sicura sono percettibilmente lenti, in base alla progettazione. Quindi potresti non voler utilizzare la vera implementazione della gestione delle identità per alcuni test, ma sostituirla con un'implementazione fittizia!

"Nel caso in cui condivido queste entità con un'altra applicazione in futuro ..." - no, questo tipo di assunzione di solito è sbagliata per due ragioni. Innanzitutto, le entità sono il modello centrale della tua applicazione. Questo di solito è unico e non riutilizzabile. Secondo, considera YAGNI. Se è necessario riutilizzare alcuni componenti, è possibile rifattorizzare il codice per renderlo riutilizzabile. È il lusso di sviluppare un'applicazione: puoi cambiare il design in un secondo momento. Al contrario, le librerie che vengono consumate esternamente devono ottenere il loro design API correttamente la prima volta.

Si noti inoltre che l'intero obiettivo dell'architettura pulita è di rinviare le decisioni di progettazione il più a lungo possibile. Ecco perché le dipendenze fluiscono solo verso l'interno. Puoi scrivere la tua logica aziendale principale, senza preoccuparti di come funzionerà davvero qualcosa. Se ha bisogno di un servizio esterno, si definisce un'interfaccia che si implementa in seguito. Come? Questo è il futuro da determinare. L'architettura pulita implica un approccio top-down al design. Decisioni come la scelta di una soluzione di gestione delle identità o la scelta di un framework web (o anche la scelta se il software è un'app Web o un'app desktop) possono essere rimandate, almeno in teoria. Trovo che sia abbastanza simile alla tecnica "Programming by Wishful Thinking " insegnata da SICP.