È di vitale importanza che tutti i dati siano verificati sul server quando proviene da un client non fidato. (Sinceramente con Javascript perché gli strumenti di hacking sono incorporati nei browser.) Quindi la domanda è se (e come) si debba riutilizzare il codice di convalida sul lato server o scrivere un codice di convalida separato per l'interfaccia utente. Ognuno ha dei compromessi.
Generalizza
In superficie, ottenere errori dal codice lato server è facile ... solo un POST AJAX lontano. Tuttavia, i messaggi di errore di stringa corrispondenti ai campi sono fragili. Solo elencare i messaggi sotto il form non è così UXified come quello che ci si aspetta al giorno d'oggi. Quindi, affinché la convalida sul lato server sia utile per altri scopi, deve essere strutturata correttamente. Ad esempio, i tuoi errori potrebbero avere identificatori che l'interfaccia utente può mappare su campi o messaggi specifici. Errori di esempio:
["UsernameTooShort", "UsernameHasInvalidCharacters"]
In questo caso, uno degli identificatori di errore è probabilmente configurato per far sì che il controllo username si illumini in rosso nell'interfaccia utente. È possibile collegare messaggi statici nell'interfaccia utente per visualizzare ciascuno di questi (se presente). Puoi inviare ulteriori informazioni con l'errore, se necessario, trasformandolo in un oggetto anziché in una stringa semplice.
[{"UsernameTooShort", "Username must be at least 8 characters."},
{"UsernameHasInvalidCharacters", "You can't use '\' in the username"}]
Potresti visualizzare i messaggi associati a questi errori direttamente invece dei messaggi statici pur sapendo a quale controllo devono applicare, i loro identificatori. Potresti anche inviare dati specifici del contesto per messaggi specifici. In entrambi i casi, gli errori non sono più semplici stringhe, il che richiederà un certo lavoro sul lato server, consapevolezza della versione perché la modifica di un identificatore potrebbe rompere i client, ecc.
Specializzarsi
Ora l'alternativa è continuare a utilizzare gli errori semplici esistenti sul server e utilizzare diversi metodi nell'interfaccia utente. Questo ha alcuni svantaggi rispetto a sopra (non una lista completa).
-
DRY - Anche se tecnicamente la regola del 3 sarà probabilmente applicata qui, quindi non può violare DRY
- Lavoro extra - Probabilmente non è più un lavoro considerando quello che devi fare per rendere gli errori riutilizzabili sul server ... tuttavia, il lavoro si estende su diversi stack tecnologici.
- Divergenza - Due implementazioni della stessa validazione possono divergere nel tempo abbastanza facilmente senza diligenza.
Ha anche alcuni vantaggi (non una lista completa):
- Può essere divergentemente intenzionalmente -
L'ho fatto dove sto creando una nuova API e importando dati che non sono stati convalidati rigorosamente. Non riesco a buttare via i dati, quindi è bello essere in grado di rendere più rilassato il lato server per adattarlo e lasciare che l'interfaccia utente applichi convalide più severe su aggiornamenti e nuovi dati. Gli utenti malintenzionati saranno comunque in grado di salvare i dati in pessime condizioni rispetto a quelli già esistenti.
- Ogni livello deve essere convalidato in un modo che abbia senso per questo. Per il server è spesso una scelta binaria di Pass / Fail (con messaggio). Per l'UX, è un po 'più coinvolto nella manipolazione di controllo / stile.
- Spesso il lato UI richiederà comunque un codice di convalida aggiuntivo non sul server a causa di tecnicismi della piattaforma. Ad esempio, la manipolazione del controllo