JavaScript: convalida lato client vs. lato server

Quale è meglio fare convalida lato client o lato server?

Nella nostra situazione stiamo usando

  • jQuery e MVC.
  • Dati JSON da passare tra la nostra vista e il controller.

Gran parte della convalida che faccio è la convalida dei dati man mano che gli utenti li inseriscono. Ad esempio, utilizzo l’evento keypress per evitare lettere in una casella di testo, impostare un numero massimo di caratteri e un numero compreso in un intervallo.

Immagino che la domanda migliore sarebbe: ci sono dei vantaggi nel fare la validazione lato server sul lato client?


Awesome risponde a tutti. Il sito Web che abbiamo è protetto da password e per una piccola base di utenti (<50). Se non stanno eseguendo JavaScript, invieremo ninja. Ma se stessimo progettando un sito per tutti, sarei d'accordo di convalidare entrambe le parti.

Come altri hanno già detto, dovresti fare entrambe le cose. Ecco perché:

Dalla parte del cliente

Si desidera innanzitutto convalidare l’input sul lato client, in quanto è ansible fornire un feedback migliore all’utente medio . Ad esempio, se immettono un indirizzo e-mail non valido e passano al campo successivo, è ansible visualizzare immediatamente un messaggio di errore. In questo modo l’utente può correggere ogni campo prima di inviare il modulo.

Se si esegue la convalida solo sul server, devono inviare il modulo, ricevere un messaggio di errore e cercare di rintracciare il problema.

(Questo dolore può essere facilitato facendo re-rendering del server con l’input originale dell’utente compilato, ma la convalida sul lato client è ancora più veloce.)

Lato server

Si desidera eseguire la convalida sul lato server poiché è ansible proteggersi da utenti malintenzionati , che possono facilmente ignorare il codice JavaScript e inviare input pericolosi al server.

È molto pericoloso fidarsi della propria interfaccia utente. Non solo possono abusare della tua interfaccia utente, ma potrebbero non utilizzare affatto l’interfaccia utente o persino un browser . Cosa succede se l’utente modifica manualmente l’URL o esegue il proprio javascript o modifica le proprie richieste HTTP con un altro strumento? Cosa succede se, ad esempio, inviano richieste HTTP personalizzate da curl o da uno script?

( Questo non è teorico, ad esempio, ho lavorato su un motore di ricerca di viaggio che ha ripresentato la ricerca dell’utente a molte compagnie aeree, compagnie di autobus, ecc. Inviando richieste POST come se l’utente avesse compilato il modulo di ricerca di ciascuna azienda, quindi raccolto e ordinato tutti i risultati. La forma di JS di queste società non è mai stata eseguita, ed è stato fondamentale per noi fornire messaggi di errore nel codice HTML restituito. Naturalmente, un’API sarebbe stata carina, ma era quello che dovevamo fare. )

Non permettere ciò è non solo ingenuo dal punto di vista della sicurezza, ma anche non standard: un client dovrebbe essere autorizzato a inviare HTTP con qualunque mezzo vogliano, e dovresti rispondere correttamente. Ciò include la convalida.

La convalida del lato server è importante anche per la compatibilità : non tutti gli utenti, anche se utilizzano un browser, avranno JavaScript abilitato.

Addendum – dicembre 2016

Esistono alcune convalide che non possono essere eseguite correttamente nel codice dell’applicazione lato server e sono completamente impossibili nel codice lato client , poiché dipendono dallo stato corrente del database. Ad esempio, “nessun altro ha registrato tale nome utente” o “il post del blog in cui stai commentando esiste ancora” oppure “nessuna prenotazione esistente si sovrappone alle date richieste” o “il saldo del tuo account è ancora sufficiente per coprire tale acquisto “. Solo il database può validamente convalidare i dati che dipendono dai dati correlati. Gli sviluppatori si avvitano regolarmente , ma PostgreSQL offre alcune buone soluzioni .

Sì, la convalida lato client può essere completamente aggirata, sempre. È necessario fare entrambe le cose, lato client per fornire un’esperienza utente migliore, e lato server per essere sicuri che l’input che si ottiene sia effettivamente validato e non solo supposto validato dal client.

Sto solo per ripeterlo, perché è abbastanza importante:

Convalidare sempre sul server

e aggiungi JavaScript per la reattività dell’utente.

Il vantaggio di eseguire la convalida lato server sulla convalida lato client è che la convalida lato client può essere ignorata / manipolata:

  • L’utente finale potrebbe avere javascript distriggersto
  • I dati potrebbero essere inviati direttamente al tuo server da qualcuno che non utilizza nemmeno il tuo sito, con un’app personalizzata progettata per farlo
  • Un errore Javascript sulla tua pagina (causato da un numero qualsiasi di cose) potrebbe comportare l’esecuzione di alcune, ma non tutte, della tua convalida

In breve, sempre, convalidare sempre lato server e quindi considerare la convalida lato client come un “extra” aggiunto per migliorare l’esperienza dell’utente finale.

Devi sempre convalidare sul server.

Anche avere la convalida sul client è piacevole per gli utenti, ma è assolutamente insicuro.

È ansible eseguire la convalida lato server e inviare un object JSON con i risultati di convalida per ciascun campo, mantenendo al minimo il javascript del client (solo visualizzando i risultati) e continuando ad avere un’esperienza user friendly senza dover ripetere se stessi sia sul client che sul server.

Bene, trovo ancora un po ‘di spazio per rispondere.

Oltre alle risposte di Rob e Nathan, aggiungerei che valgono le convalide sul lato client. Quando applichi le convalide sui tuoi moduli web, devi seguire queste linee guida:

Dalla parte del cliente

  1. È necessario utilizzare le convalide sul lato client per filtrare le richieste autentiche provenienti da utenti autentici sul proprio sito Web.
  2. La convalida lato client deve essere utilizzata per ridurre gli errori che potrebbero verificarsi durante l’elaborazione lato server.
  3. La convalida lato client deve essere utilizzata per ridurre al minimo i round trip sul lato server, in modo da risparmiare larghezza di banda e richieste per utente.

Lato server

  1. NON SI DEVE assumere che la validazione eseguita con successo al cliente sia perfetta al 100%. Non importa anche se serve meno di 50 utenti. Non sai mai quale dei tuoi utenti / emplyee si trasformi in un “male” e fai qualche attività dannosa sapendo che non hai valide convalide in atto.
  2. Anche se è perfetto in termini di convalida dell’indirizzo di posta elettronica, dei numeri di telefono o della verifica di alcuni input validi, potrebbe contenere dati molto dannosi. Che deve essere filtrato sul lato server, non importa se è corretto o errato.
  3. Se la convalida sul lato client viene ignorata, le convalide sul lato server vengono per salvarti da potenziali danni all’elaborazione lato server. Negli ultimi tempi, abbiamo già sentito molte storie di Iniezioni SQL e altri tipi di tecniche che potrebbero essere applicate per ottenere alcuni benefici negativi.

Entrambi i tipi di convalida svolgono ruoli importanti nei rispettivi ambiti, ma il più forte è il lato server. Se ricevi 10k utenti in un singolo punto del tempo, finirai per filtrare il numero di richieste che arrivano sul tuo server web. Se trovi che c’è stato un solo errore come un indirizzo e-mail non valido, essi postano di nuovo il modulo e chiedono all’utente di correggerlo, il che sicuramente mangerà le risorse del tuo server e la larghezza di banda. Quindi meglio si applica la convalida javascript. Se javascript è disabilitato, la convalida del server verrà in soccorso e scommetto che solo alcuni utenti potrebbero averlo disabilitato accidentalmente poiché il 99,99% dei siti web utilizza javascript e è già abilitato di default in tutti i browser moderni.

Il lato client deve utilizzare una convalida di base tramite tipi di input HTML5 e attributi di pattern e questi vengono utilizzati solo per miglioramenti progressivi per una migliore esperienza utente (anche se non sono supportati su

JavaScript può essere modificato in fase di runtime.

Suggerisco un modello di creazione di una struttura di convalida sul server e la condivisione con il client.

Avrai bisogno di una logica di validazione separata su entrambe le estremità, ad esempio:

attributi "required" sugli inputs lato client

field.length > 0 lato server.

Tuttavia, l’uso della stessa specifica di convalida eliminerà alcune ridondanze (ed errori) della convalida del mirroring su entrambe le estremità.

Suggerirò di implementare la validazione sia del client che del server per mantenere il progetto più sicuro …… se dovessi sceglierne uno andrò con la validazione lato server.

Aggiornamento del 23 luglio 2018: il seguente link non è più accessibile:

Puoi trovare alcune informazioni rilevanti qui http://www.webexpertlabs.com/server-side-form-validation-using-regular-expression/

Mi sono imbattuto in un link interessante che fa una distinzione tra errori grossolani, sistematici, casuali.

Client-Side validation adatta perfettamente alla prevenzione di errori grossolani e casuali. In genere una lunghezza massima per texture e input. Non imitare la regola di convalida sul lato server; fornire la propria regola di convalida grossolana, regola del pollice (ad esempio 200 caratteri sul lato client; n sul lato server, dettata da una regola aziendale valida).

Server-side validation adatta perfettamente alla prevenzione degli errori sistematici; imporrà regole aziendali.

In un progetto in cui sono coinvolto, la convalida viene eseguita sul server tramite richieste Ajax. Sul client visualizzo i messaggi di errore di conseguenza.

Ulteriori letture: errori grossolani, sistematici, casuali:

https://answers.yahoo.com/question/index?qid=20080918203131AAEt6GO

Se stai facendo una leggera convalida, è meglio farlo sul client. Risparmierà il traffico di rete che aiuterà il tuo server a funzionare meglio. Se è complicata la convalida che consiste nel prelevare dati da un database o qualcosa del genere, come le password, allora è meglio farlo sul server dove i dati possono essere controllati in modo sicuro.