Lorsque des validations côté client et serveur se produisent, cela ne permet-il pas à une meilleure UX de ne faire que des validations serveur?
Je trouve un problème sur le projet MVC4 sur lequel je travaille actuellement, à l'aide de la validation Fluent, en ce que certaines validations sont déléguées à la validation côté client jQuery, tandis que d'autres, telles que la règle NotNull pour les listes déroulantes, et certaines validations conditionnelles basées sur les valeurs de champ , doit être fait sur le serveur.
Il en résulte que l'utilisateur laisse certaines listes déroulantes et certaines zones de texte vides, ou sélectionne une certaine valeur dans une liste déroulante. Ils appuient ensuite sur Soumettre et obtiennent des messages pour les validations côté client, qu'ils corrigent. Ils cliquent ensuite à nouveau sur Soumettre, puis obtiennent à nouveau d'autres messages pour les validations côté serveur, qu'ils doivent corriger et cliquez à nouveau sur Soumettre.
J'ai environ 5% de mes pages où la validation côté serveur n'est pas requise, donc je pense que désactiver le côté client permettra une bien meilleure UX. L'utilisateur obtiendra tous ses messages de validation en même temps, peut tenter toutes les corrections en même temps, soumettre à nouveau.
J'utilise la règle de validation côté serveur pour la sécurité et la validation côté client pour la convivialité.
Je ne peux faire confiance à aucun client, mais je peux écrire un client standard qui valide rapidement (sans le réseau) les entrées, de sorte que l'utilisateur peut obtenir une réponse parfois même en tapant.
Cela minimise également les demandes erronées que mon client envoie à mon serveur.
-- ÉDITER --
Ce que je veux dire, c'est:
Vous pouvez effectuer la validation sans passer de temps à la validation côté client et obtenir des résultats décents .
Pro:
- Il suffit d'implémenter une validation.
- Aucun message d'erreur de niveau 2, juste un du serveur.
Contra:
- Pour chaque entrée défectueuse vous obtenez une requête défectueuse à votre serveur, même seul le client que vous avez implémenté est utilisé.
- Les utilisateurs doivent attendre une réponse du serveur pour savoir ce qui ne va pas.
Ce dont vous avez besoin est probablement d'implémenter deux validateurs, qui prennent la même configuration, vous n'avez donc pas à écrire la configuration pour le client et serveur. Ce qui éliminerait le problème avec les 2 erreurs de niveau et vous obtenez les avantages de la validation côté client.
C'est énervant. Votre utilisateur remplit le formulaire, le soumet et récupère "3 erreurs". Il corrige ces 3 erreurs, soumet et récupère "2 nouvelles erreurs" dans des domaines qu'il n'a pas changé entre-temps. Sa réaction:
"Pourquoi ne m'avez-vous pas parlé de ces 2 erreurs en premier lieu"?
Et il a raison.
La validation côté client était destinée à aider l'utilisateur en fournissant des commentaires plus rapides. Attendre que l'utilisateur clique sur "soumettre" vous fait perdre la majeure partie de cet Edge: vous enregistrez uniquement le temps d'aller-retour sur le serveur, qui de nos jours est souvent minimal. Surtout quand il s'agit du coût de deux soumissions, la validation côté client n'aide pas l'utilisateur, mais l'ennuie.
Deux correctifs:
1/Que la solution côté client soit immédiate: dès qu'un utilisateur entre une mauvaise adresse e-mail (le champ devient flou), donnez un indice (affichez une boîte, le champ rouge) que l'adresse e-mail a le mauvais format et ne sera pas acceptée par le serveur de toute façon.
2/Si la solution côté client ne peut pas être immédiate, désactivez-la tout à fait. Avoir une validation côté serveur qui détecte TOUTES les erreurs et les montre TOUT en une (ne vous arrêtez pas à la première erreur, demandez à l'utilisateur de corriger cela, répétez pour chaque erreur).
Dans un monde parfait, la vérification côté client détecte toutes les erreurs possibles qu'un utilisateur peut faire, mais nous savons souvent que ce n'est pas possible. Les utilisateurs s'y sont également habitués: personne ne deviendra fou si la validation côté client ne détecte qu'un sous-ensemble des erreurs que la validation côté serveur détecte.
C'est pourquoi j'ai souvent ne code que les erreurs les plus courantes à 80% dans le côté client, et laisse les cas Edge pour le côté serveur. Si une erreur la plus courante ne peut être vérifiée qu'au niveau du serveur (par exemple "nom d'utilisateur déjà pris"), une petite demande AJAX peut faire des merveilles: pendant que l'utilisateur continue de remplir le formulaire, il remarquera son nom d'utilisateur a déjà été pris et peut le changer en quelque chose d'autre.
Je suis un grand fan de validations de serveur à la volée.
Lorsque vous ne traitez pas d'énormes quantités de données (téléchargements de fichiers volumineux, etc.), il n'est pas trop difficile de soumettre automatiquement AJAX à un serveur pour validation. Cela se voit généralement dans les formulaires d'inscription où les utilisateurs doivent choisir un nom d'utilisateur unique en plus de saisir leur adresse e-mail, leur mot de passe, etc.
tilisation du modèle de validation client + serveur
- Entre un nom d'utilisateur "I-Love-Kittenz"
- Erreur côté client "Vous ne pouvez pas avoir de caractères spéciaux"
- Change le nom d'utilisateur en "ILoveKittenz"
- Le côté client ne donne aucune erreur
- L'utilisateur soumet le formulaire
- Erreur côté serveur "Ce nom d'utilisateur est déjà pris!"
- L'utilisateur est frustré et essaie un autre nom d'utilisateur
tilisation du modèle de validation de serveur à la volée
- Entre un nom d'utilisateur "I-Love-Kittenz"
- Le client interroge le serveur et obtient l'erreur "Vous ne pouvez pas avoir de caractères spéciaux"
- Change le nom d'utilisateur en "ILoveKittenz"
- Le client interroge le serveur et obtient l'erreur "Ce nom d'utilisateur est déjà pris!"
- Change le nom d'utilisateur en "ILoveK1ttenz"
- Le client interroge le serveur et obtient OK
- L'utilisateur soumet et est heureux!
La validation côté client est généralement souhaitable car elle est rapide. La validation est effectuée avant l'envoi du formulaire. L'utilisateur n'a pas à attendre plusieurs secondes avant que le serveur ne réponde.
La validation côté serveur est généralement requise car les utilisateurs sans javascript ou les utilisateurs malveillants peuvent soumettre de mauvaises données sans lui.
La meilleure pratique consiste généralement à demander aux deux de faire la validation même afin qu'elle soit rapide pour les utilisateurs, mais le serveur est protégé contre les données incorrectes.
L'utilisateur n'a pas besoin de savoir comment ni où quelque chose a été validé.
Effectuez les deux validations et affichez les erreurs des deux validations dans la même boîte de dialogue. Cela supprimera l'expérience décevante d'avoir validé, corrigé et validé et corrigé à nouveau. L'utilisateur sait immédiatement ce qui ne va pas et sait résoudre tous les problèmes après la première invite d'erreur.
Vous pouvez vous passer de la validation côté client, mais vous ne pouvez pas vous passer de la validation côté serveur.
Pas de si, pas de mais.
Si vous souhaitez que votre site soit piraté, comptez sur la validation côté client.
La validation côté client doit être utilisée pour minimiser le nombre d'erreurs détectées par la validation côté serveur. Il ne doit pas être utilisé à la place de la validation côté serveur.
Cependant, si vous comptez sur la validation côté serveur, vous pouvez vous retrouver avec un vrai gâchis, si le formulaire est à distance compliqué. Utilisez donc les deux si vous voulez le meilleur résultat, ou utilisez le côté serveur uniquement si vous voulez une facilité de programmation et un point unique pour vos règles métier. Mais n'utilisez jamais le côté client uniquement. Déjà.
Vous devez valider à la fois côté client et côté serveur, voir la réponse ci-dessus pour les raisons. Votre utilisateur bénéficiera d'une expérience plus rapide/réactive et votre serveur vous remerciera d'avoir arrêté les tentatives non valides avant qu'elles ne soient soumises.
Je pense que vous rencontrez un autre problème: mauvaise utilisation ou méconnaissance des méthodes de validation MVC 4:
- Oui, vous pouvez et devez valider la règle non nulle pour les listes déroulantes côté client. Voir obligatoire attribut.
- Oui, vous pouvez et devez valider les règles conditionnelles côté client. Voir Attribut distant et autre attributs personnalisés .
Votre problème n'est pas que vous ayez à la fois une validation côté client et côté serveur. Votre problème est que votre côté client valide les choses que le serveur ne fait pas. C'est complètement inutile.
La validation côté client ne doit jamais valider plus que le serveur. Son objectif est de ne pas perdre de temps utilisateur/ressources serveur pour découvrir quelque chose qui peut déjà être déterminé sur l'ordinateur de l'utilisateur, c'est-à-dire qu'il échouera. Le serveur valide très fréquemment des choses que le client ne devrait jamais, en utilisant une logique métier que vous ne voudriez pas exposer à l'utilisateur.
Alors oui, chaque fois que vous avez quelque chose sur le client qui définit des règles plus strictes que le serveur, désactivez-le. Si vous utilisez une solution unique pour tous du côté client, vous pouvez envisager une solution que vous pouvez personnaliser en fonction de chaque scénario.
Si vous désactivez la validation côté client sur toutes vos pages comme vous le suggérez, obtiendrez-vous vraiment tous vos messages de validation en même temps? Je trouve qu'en pratique, la plupart des formulaires non triviaux nécessitent une validation en deux étapes, quelle que soit la technique de validation côté client vs serveur:
- Validation des entrées - par ex. Champs obligatoires
- Validation des règles métier - par exemple combinaison de sélections sont valables dans le contexte commercial plus large.
Cela dit, j'ai renoncé à la validation côté client il y a des années. J'ai trouvé que les inconvénients l'emportaient systématiquement sur les avantages.
Les inconvénients:
- Effort de programmation en double (la validation doit également être effectuée sur le serveur) ou recours à des bibliothèques comme FluentValidation pour fonctionner comme vous en avez besoin.
- Effort de test en double
- Expérience utilisateur incohérente. c'est-à-dire que la validation côté client est généralement presque instantanée, presque saccadée. La validation côté service a un délai.
- ...
Avantages:
- Plus rapide pour l'utilisateur
- Moins de charge sur le serveur
Cependant, si vous allez à 100% côté serveur, vous voudrez passer des POST pleine page aux POST Ajax, si vous ne l'avez pas déjà fait. Cela rendra votre temps de demande/réponse beaucoup plus rapide (en cas d'échec de validation, vous ne retournez par exemple qu'une liste de résultats de validation, plutôt que d'avoir à reconstruire la page entière). Plus facile à dire qu'à faire, il n'y a pas beaucoup de bibliothèques/frameworks prêts à l'emploi qui prennent en charge ce paradigme, mais valent bien l'effort à bien des égards, y compris la validation dont nous discutons ici.