Validation des données

Hello PapyJP,

Pour ma part je vérifie systématiquement chaque input en JS.

Bien entendu tout dépend des données, mais en gros je vérifie que:
_ l'input ne contient pas de code ( pour sécuriser coté injection )
_ la chaine correspond bien au format attendu ( tél, mail, texte, pseudo, chaine vide, etc)
_ éventuellement la chaine ne doit pas contenir de mots interdits dans une liste
_ éventuellement interdire le collage
_ éventuellement une question anti-robot

Si tout est "bon" j'envoie au php pour revérification et traitement.

C'est très difficile de pré-vérifier tous les cas foireux

Moi je vérifierais les données côté client avec les nouvelles moutures proposées par HTML5 (pattern). Sauf pour un site sous node.js où du coup j'utiliserai les mêmes conditions JS des deux côtés (front et back), pour le côté pratique de réutilisation du code mais surtout pour plus de cohérence.
Modifié par Olivier C (13 Apr 2020 - 22:14)

Merci de vos réponses
Quel est l’interêt de faire la vérification deux fois, une fois avant d’envoyer les données, une deuxième fois à la réception ?
Ça pourrait être intéressant de vérifier au onchange lors de la saisie de chaque champ, mais il n’y a pas toujours d’équivalent javascript pour les fonctions de vérification de PHP.
En particulier pas de traitement des chaînes de caractères utf-8. Comment faire en javascript pour tester que « François » est un prénom valide mais que « Fran@ois » ne l’est pas?

Et l'eau,

PapyJP a écrit :

Quel est l’interêt de faire la vérification deux fois, une fois avant d’envoyer les données, une deuxième fois à la réception ?

Pourquoi vérifier 2 fois ? La vérification frontend permet de soulager le serveur ! Imagine 100xxxxx utilisateurs remplissant mal le formulaire et le soumettent.

PapyJP a écrit :

Ça pourrait être intéressant de vérifier au onchange lors de la saisie de chaque champ, mais il n’y a pas toujours d’équivalent javascript pour les fonctions de vérification de PHP.

Tu n'as qu'à le coder

PapyJP a écrit :

En particulier pas de traitement des chaînes de caractères utf-8. Comment faire en javascript pour tester que « François » est un prénom valide mais que « Fran@ois » ne l’est pas?

- expreg
- regex101
- includes
- etc.
Modifié par niuxe (14 Apr 2020 - 00:07)

PapyJP a écrit :
Quel est l’interêt de faire la vérification deux fois, une fois avant d’envoyer les données, une deuxième fois à la réception ?

En plus de la réponse de Niuxe plus haut : ça permet de donner un retour d'erreur à l'utilisateur sans devoir recharger la page.

Olivier C a écrit :

En plus de la réponse de Niuxe plus haut : ça permet de donner un retour d'erreur à l'utilisateur sans devoir recharger la page.

Oui surtout sans devoir attendre… 

@Papy, d'un point de vue utilisateur, imagine un assez long formulaire à devoir remplir et tu ne dois attendre d'avoir rempli le 20ème champs pour soumettre et ensuite repasser le tout en revue pcq tu as une erreur au début et à la fin…

Cela fonctionne aussi avec une formulaire de seulement 3 champs, imagine une création de password, tu expliques peut-être les règles de compléxité minimum de sécurité mais certaines personnes ont du mal avec ça, tu pourrais leur signaler tout de suite.

Il me semble que ce sont les 2 atouts, économiser les ressources serveurs et utiliser la machine client pour filtrer une première fois. Et ensuite évidement, l'expérience utilisateur.

Merci à tous, ça donne du grain à moudre.

Je ne crois pas que faire les vérifications en local réduise la charge du serveur, car on les refait tout de même sur le serveur. Tout au plus ça la réduit légèrement en faisant les vérifications à la volée au cours de la saisie, permettant à l'utilisateur de corriger sur le champ.

Pour le site et les fonctions qui m'intéressent pour le moment, il s'agit de fonctions d'administration qui ont moins d'une dizaine d'utilisateurs, il ne peut donc pas y avoir d'effet d'avalanche. De même je peux considérer qu'il n'y a pas de tentatives d'intrusion volontaire, les utilisateurs en cause ayant dû montrer patte blanche avant d'accéder au formulaire. Ça n'évite pas bien entendu d'avoir à se protéger de fautes de frappe ou copier/coller qui accidentellement apporteraient des scories.

Pour moi, la véritable raison est donc de faire les vérifications au moment de la saisie, c'est à dire sur les onchange des balises <input> pour guider l'utilisateur.

En ce qui concerne la vérification de la validité des champs JavaScript, le point manquant est un convertisseur de TOUS les caractères latins (y compris roumain, tchèque, hongrois, letton, ...) en 'plain ascii'.
Vérifier que est un nom de compositeur aussi valable que "Claude Debussy" nécessite un convertisseur puissant que je ne me sens pas le courage de coder.
C'est ce que fait très bien la fonction PHP

iconv("UTF-8", "ASCII//TRANSLIT//IGNORE", transliterator_transliterate('Any-Latin; Latin-ASCII', $text))

qui me rend "Arijs Skepasts"
Une fois la conversion effectuée , pas de problème pour vérifier avec un regex simple que le texte converti en ascii est compatible avec un nom ou un prénom.
Modifié par PapyJP (14 Apr 2020 - 11:08)

J'ai trouvé cette page qui fournit un programme de conversion tel que je le cherche.
http://www.vingtseptpointsept.fr/2011/09/22/une-fonction-javascript-pour-eliminer-accents-et-diacritiques/
Pas sûr que ce soit vraiment utilisable, je vais essayer.

J'ai essayé, ça semble marcher.
Je vais donc l'utiliser pour la vérification des champs à la volée, ce qui n'empêchera pas de les tester à nouveau sur le serveur. L'alternative aurait été de tester à la volée sur le serveur en AJAX, ce qui -- outre la surcharge du serveur -- risquait de se traduire par un temps de réponse gênant pour l'utilisateur.

Merci à tous pour m'avoir aidé à clarifier mes idées sur ce sujet.
Retraité + confiné, ça augmente l'importance des échange par Internet...
Modifié par PapyJP (14 Apr 2020 - 11:52)

@JPB
Je suis désolé nous ne nous sommes pas bien compris.
Le site, la BDD, etc sont tous en UTF-8 depuis l'origine (1999).
Je n'ai JAMAIS besoin de convertir les données en ASCII, SAUF que c'est temporairementla seule façon pratique que j'ai trouvée pour faire des tests sur la validité de certains champs.
Si j'écris var composerName = ;
et que je veux tester si cette chaine de caractères ne contient que ce qu'on doit trouver dans le nom d'une personne, c'est à dire rien d'autre que des lettres, des tirets des espaces et des apostrophes, le plus simple est de convertir ce nom en ASCII et de vérifier ensuite:

var asciiName = toPlainASCII(composerName);
if(asciiName.match(/- 'A-Za-z/)) ...

Il s'agit de musique occidentale, les noms que nous manipulons sont tous en caractères "latin étendu". La tradition (à tort ou à raison) veut qu'on translittère les noms en Cyrillique ou autre alphabet non latin, mais qu'on conserve les signes diacritiques sur les noms écrits en caractères latins étendus.
Je dois donc pourvoir entrer et vérifier la validité de ces noms.
Comme de toute façon c'est déjà partiellement valable pour notre propre langue, ce n'est pas réellement un problème dès l'instant où on dispose d'une solution qui marche pour le latin étendu, ça inclut le français.
Modifié par PapyJP (14 Apr 2020 - 12:07)

Oui, ça marche en PHP, avec ce que je viens de trouver ça va marcher en JavaScript.
J'en suis content, car ce qui compte pour moi c'est toujours l'utilisateur et je vais pouvoir améliorer l'utilisation de l'appli.

Je ne vais pas me lancer dans le radotage, sache simplement que la première phrase de mon cours sur la conduite de projet c'était :
"Un projet a pour but de satisfaire certains besoins de certains utilisateurs"
Le mot "certains" étant primordial, car "satisfaire les besoins des utilisateurs" se comprend comme "tous les besoins de tous les utilisateurs", et ça c'est le genre de projet qui ne peut pas aboutir.

Mon code commence à marcher comme je voudrais
Une question annexe : quel mécanisme utiliser pour signaler une erreur à l’utilisateur ?
Pour l’instant j’ai mis un message à côté de la balise <input> (ou autre). Mais ça ne me plaît guère
Modifié par PapyJP (14 Apr 2020 - 16:47)

Tu peux regarder du coté de sweet alert > https://sweetalert.js.org/guides/
C'est une sorte de alert() mais en plus fun et joli pour l'utilisateur.
C'est personnalisable à souhait !

C'est ce que j'avais commencé à faire (une div de message modale) mais j'ai trouvé que c'était un peu trop...

PapyJP a écrit :
Pour l’instant j’ai mis un message à côté de la balise input (ou autre). Mais ça ne me plaît guère

Accompagné par un design spécifique pour l'input ça passe très bien je trouve : Inputs

Effectivement ce design me semble très bien, en tout cas bien meilleur que ce que j’avais fait
Merci à tous pour votre aide très constructive