Progettazione della mia classe di password. Come dividerlo?

Question

Progettazione della mia classe di password. Come dividerlo?

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

1

Ho ereditato un sistema di autenticazione personalizzato che necessita di alcuni refactoring. Non sono del tutto sicuro di quale sia il modo migliore per suddividere la sezione della password e potrebbe servirci di aiuto.

Le classi password richiedono la seguente funzionalità:

Verifica se una password è conforme alle restrizioni. Deve essere in grado di fornire un feedback sul motivo per cui è errata.
Genera tre tipi di hash. Abbiamo diversi file system con hash incompatibili, quindi sfortunatamente devo mantenere tre hash.
Fornisci un hash diverso per un determinato tipo di utente. Se un utente è solo Web, non conserviamo una password perché non possono utilizzare il sistema. Le loro password sono sempre * .
Essere in grado di verificare una password per un determinato utente. Fortunatamente devo solo autenticarmi con uno dei tre hash che devo mantenere.
Essere in grado di generare una password casuale, non crittografata.
Invia nuova password al database.

Sto pensando di utilizzare quattro classi, Validator , Hasher , Generator e Changer .

Validator
- isCurrentPassword(int userid, string password): bool
- getViolations(string password): array
Generator
- generate(int length):string Crea una password.
Hasher
- hash_*(string password): string dove * è il tipo di hash. Avrò quattro funzioni di hashing.
Changer
- change(int userid, string password):void; throws database exceptions

Che cosa consiglieresti e perché?

design php

posta Levi Morrison 05.01.2012 - 00:54

fonte

3 risposte

Leggi altre domande sui tag design php

Due diverse forme di user story, sono entrambe corrette? Creazione di un'applicazione HTML5 per Android e iOS

score 2 · Answer 1

Chi altro dovrebbe utilizzare questo sistema di autenticazione? Se è solo la tua applicazione, usa il codice più semplice possibile che possa essere compreso, mantenuto e testato. Tuttavia, non vedo che dovresti usare 2 classi separate come nel metodo 1, perché Validator non è una classe, è strettamente un metodo di qualche classe. Lo stesso vale per Generator.

score 0 · Answer 2

Verifica se una password è conforme alle restrizioni

Penso che questo appartenga alla sua classe. Nel tuo metodo 1, hai ottenuto come parte della classe Validator. Ma non ha le stesse dipendenze di isCurrentPassword o condivide i dettagli di implementazione. Di conseguenza, inserivo una classe PasswordAudit separata.
Genera tre tipi di hash

Dovresti avere una sorta di interfaccia che fornisce un accesso uniforme ai diversi filesystem che stai utilizzando. Suggerirei che la funzione hash() debba essere utilizzata lì. È un dettaglio di implementazione del filesystem e appartiene alla gestione di quel filesystem
Fornisci un hash diverso per un determinato tipo di utente

Se non possono usare il sistema, perché hanno account? O forse possono accedere al sistema web, ma non hanno accesso ai back-end del filesystem? Ma in quel caso, avrebbero ancora una password, vero?

Suggerirei di implementarlo con un backend NullFileSystem. Il backend supporta l'interfaccia di un filesystem, ma in realtà non funziona. Sostituire l'hash è facile.
Essere in grado di verificare una password per un determinato utente.

Sarei propenso a utilizzare l'oggetto utente per questo scopo. Avrebbe un metodo di autenticazione che determina se la password specificata corrisponde all'oggetto utente.

Naturalmente, ho solo intravisto quello che stai facendo, quindi i miei suggerimenti potrebbero o non hanno alcun senso.

score 0 · Answer 3

Penso che ti occorrono 2 interfacce:

IPasswordValidator: convalida la password / gestisce la messaggistica dell'interfaccia utente sulla convalida.
IAuthenticationScheme: gestisce l'autenticazione / l'hashing / l'aggiornamento delle password

IPasswordValidator probabilmente ha bisogno solo di un'implementazione concreta, ma è abbastanza semplice metterlo dietro un'interfaccia per documentare almeno il contratto. La testabilità è un bonus. IPasswordValidator copre il metodo getViolations.

IAuthenticationScheme è il luogo in cui avviene il divertimento: qui è dove si collegano i propri schemi di hashing alternativi e qualsiasi altra dipendenza dei dati. Nel tuo schema originale questo combina hasher e changer e le tue classi e metodi isCurrentPassword.

La generazione non è davvero una preoccupazione coperta in entrambi, sarebbe probabilmente meglio lasciarla a una libreria di utilità. Se la generazione dipende dall'implementazione, ad esempio se un determinato provider ha requisiti particolari, è possibile spostare la generazione in IAuthenticationScheme.