Convalida del server sacrificio in termini di prestazioni con convalida Rich Client?

0

Recentemente ho iniziato a lavorare in un progetto enterprise java (~ 200 persone) che usa un client ricco SWT. In molti casi ho riscontrato che le regole aziendali non vengono convalidate sul lato server, perché i widget che attivano tali azioni sono disabilitati nel client SWT utilizzando le regole aziendali.

Questa è una questione ben nota di convalida in server, client o server + client e non sto indicando lo stesso problema. Inoltre, sono favorevole alla convalida in server + client.

La necessità di convalida nel client è ovvia perché consente un'applicazione più reattiva per l'utente finale e meno richieste per il server.

La necessità di convalida nel server è evidente con un client Web, in cui è possibile giocare con html e javascript per evitare le convalide sul lato client e inviare dati errati al server.

Ma con un client SWT questo non è così semplice (potrebbe essere ottenuto con uno sniffer di pacchetti come Wireshark?) quindi si potrebbe sostenere che la convalida nel server avrebbe un costo innescato in termini di prestazioni. Sempre in uno scenario in cui vi è un solo punto di accesso all'applicazione ed è il client SWT.

Se il progetto fosse iniziato ieri, mi batterò per la validazione server + client, ma in un progetto con 8 anni di storia questo potrebbe essere difficile perché dovremmo convincere gli utenti finali e gli analisti dei vantaggi della penalizzazione delle prestazioni.

Quindi, ogni volta che trovo uno di questi buchi di convalida, faccio fatica ad aggiungere la validazione lato server o lasciarlo andare, pensando "il client lo acchiapperà e questo non accadrà mai" e continuerò con un compito più prioritario.

Questo progetto è stato produttivo per quattro anni, quindi è una pratica praticabile, ma dal punto di vista del design, è corretto questo approccio? Aniway Penso che questa sia una conseguenza e non qualcosa di deliberatamente cercato.

Potrebbe essere preso come una decisione politica con conoscenza delle conseguenze o il mondo del software dirà NO a questa pratica?

    
posta gabrielgiussi 31.07.2015 - 16:15
fonte

3 risposte

3

Considera due opzioni.

  1. Convalidare tutto sul server, in ogni momento. Supponi di pagare per 2 settimane extra di tempo per lo sviluppatore (ad esempio $ 10k) e ad es. $ 100 / mese extra per una maggiore potenza di calcolo. Non succede nulla di interessante.

  2. Non convalidare l'input e risparmiare tempo e denaro. Poi qualcuno dispettoso ruba un segreto, scopre che il lato server consente di fare qualsiasi cosa e provoca il caos che ti costa $ N. Per impedirlo in futuro, implementa tardivamente l'opzione 1.

Se $ N è sufficientemente piccolo, potrebbe essere razionale optare per l'opzione 2. Ma dubito strongmente che per un progetto che ingaggia ~ 200 sviluppatori questo potrebbe essere vero.

    
risposta data 31.07.2015 - 19:51
fonte
2

Direi di no, non è così. La ragione è che chiunque può annusare il traffico di rete per vedere quali sono le tue chiamate, e se non stai convalidando, stai aprendo rischi di sicurezza e rischi di corruzione dei dati.

La razionalizzazione delle prestazioni non regge; ci sono problemi di prestazioni sul client che eseguono le regole? In caso contrario, non dovrebbero neanche essere in esecuzione le stesse regole sul server. Hai persino provato a implementare la convalida sul server per vedere quale sarebbe la penalizzazione delle prestazioni? Dalla tua domanda sembra che la risposta non ci sia, e che i problemi di prestazione siano un motivo dopo il fatto di non farlo.

Non importa se questa è una sola applicazione interna; stai facendo affidamento sul firewall della tua azienda per tenere fuori gli intrusi, ma il problema è che il firewall potrebbe non riuscire a farlo. Anche le tue app devono essere sicure; questo è noto come profondità di difesa. Non puoi fare affidamento su nessun sistema per la tua sicurezza.

Se vuoi giustificarlo, annota semplicemente una delle chiamate dal client al server in qualcosa come Wireshark o Fiddler, alteralo, ad esempio, rendi il prezzo zero, o modifica alcuni dati per non essere valido in modo tale che non sia valido causare perdite all'azienda e quindi licenziare tale richiesta (contro un ambiente di test, ovviamente). Se questo non li convince, non so cosa lo farà.

    
risposta data 31.07.2015 - 18:52
fonte
0

Come hai sottolineato, è la cosa migliore da fare per la convalida lato client e lato server. Vuoi la convalida del lato client in modo da poter fornire rapidamente un feedback all'utente e lo vuoi lato server perché spesso le persone che scrivono il codice del server non sono le stesse persone che scrivono il codice client ed è necessario controllare le ipotesi.

Tuttavia, il codice è stato in esecuzione in produzione per 4 anni senza problemi evidenti. Se sono state aggiunte le convalide del server mancanti (probabilmente a costi considerevoli), il codice continuerebbe a essere eseguito senza problemi evidenti.

Sfortunatamente, il ROI sul fixing è quasi zero.

Se al momento aggiungi il codice di convalida del server, devi considerare il costo di garantire che esegua esattamente gli stessi controlli del codice lato client (compresi eventuali bug nel codice client).

Il grande valore dei controlli lato server in questo scenario (rich client) è durante lo sviluppo, non dopo che il sistema è in produzione, stabile e relativamente privo di bug.

    
risposta data 31.07.2015 - 17:47
fonte

Leggi altre domande sui tag