La convalida dell'input dei dati è sempre stata una lotta interna per me.
Sull'orlo di aggiungere un vero framework e codice di sicurezza al nostro progetto di riscrittura delle applicazioni legacy (che finora mantiene pressoché il codice di sicurezza legacy e la convalida dei dati), mi chiedo nuovamente su quanto dovrebbe Convalido, dove, ecc.
Durante i miei 5 anni come sviluppatore Java professionista, ho creato e perfezionato le mie regole personali per la convalida dei dati e le misure di sicurezza. Poiché mi piace migliorare i miei metodi, mi piacerebbe che alcuni ascoltassero alcune idee da voi ragazzi. Le regole e le procedure generali vanno bene e anche quelle specifiche di Java.
Riepilogati, queste sono le mie linee guida (esposte su uno stile di applicazione web a 3 livelli), con brevi spiegazioni:
-
Lato client di primo livello (browser): convalida minima, solo regole invariabili (campo email obbligatorio, deve selezionare un elemento e simili); utilizzo di convalida aggiuntiva come "tra 6 e 20 caratteri" meno frequente, in quanto ciò aumenta il lavoro di manutenzione sulle modifiche (può essere aggiunto una volta che il codice aziendale è stabile);
-
Lato server di primo livello (gestione delle comunicazioni web, "controller"): non ho una regola per questo, ma credo che solo la manipolazione dei dati e gli errori di assemblaggio / analisi debbano essere gestiti qui (il campo di compleanno è non una data valida); l'aggiunta di ulteriori convalide qui rende facilmente un processo davvero noioso;
-
2 ° livello (livello aziendale): validazione solida, non meno; dati in ingresso, intervalli, valori, controllo dello stato interno se il metodo non può essere chiamato in qualsiasi momento, ruoli / permessi utente e così via; utilizzare il minor numero possibile di dati di input dell'utente, recuperarlo di nuovo dal database, se necessario; se consideriamo anche i dati del database recuperati come input, lo convaliderei solo se alcuni dati specifici sono inaffidabili o danneggiati sul DB - la tipizzazione strong fa la maggior parte del lavoro qui, IMHO;
-
3 ° livello (livello dati / DAL / DAO): non ho mai creduto che fosse necessaria molta convalida qui, dato che solo il livello aziendale dovrebbe accedere ai dati (convalidare forse in alcuni casi come "param2 non deve essere nullo se param1 è vero "); nota comunque che quando intendo "qui" intendo "codice che accede al database" o "metodi di esecuzione SQL", il database stesso è completamente l'opposto;
-
il database (modello dati): deve essere altrettanto pensato, strong e auto-attuante da evitare il più possibile dati errati e corrotti sul DB, con buone chiavi primarie, chiavi esterne, vincoli, tipo di dati / lunghezza / dimensione / precisione e così via - Lascio i trigger fuori da questo, poiché hanno una loro discussione privata.
So che la convalida dei dati in anticipo è buona e dal punto di vista delle prestazioni, ma la convalida dei dati ripetuta è un processo noioso e ammetto che la convalida dei dati è piuttosto fastidiosa. Ecco perché così tanti programmatori lo saltano o lo fanno a metà strada. Inoltre, ogni convalida duplicata è un possibile errore se non sono sincronizzati tutte le volte. Queste sono le ragioni principali per le quali oggi preferisco lasciare la maggior parte delle convalide al livello aziendale, a scapito di tempo, larghezza di banda e CPU, eccezioni gestite caso per caso.
Quindi, cosa ne pensi di questo? Opinioni opposte? Hai altre procedure? Un riferimento a tale argomento? Qualsiasi contributo è valido.
Nota: se stai pensando al modo di fare Java, la nostra applicazione è basata su Spring con Spring MVC e MyBatis (le prestazioni e il modello di database errato escludono le soluzioni ORM); Ho intenzione di aggiungere Spring Security come nostro fornitore di sicurezza oltre a JSR 303 (Hibernate Validator?)
Grazie!
Modifica: ulteriori chiarimenti sul terzo livello.