Informatique

// Verification of user input: removing leading and trailing spaces, removing backslashes, converting special characters to HTML entities
function verifyInput($data)
{
    $data = trim($data);
    $data = stripslashes($data);
    $data = htmlspecialchars($data);
    return $data;
}

Bonjour,

Je voudrais savoir si cela est suffisant ?

Si tu utilises les paramètres GET, POST, etc, tu as la fonction filter_input.

C'est mieux ?

Mais tu veux faire quoi au juste ?

Controler les inputs des utilisateurs quand ils font des comptes ou envoie des messages

Dans ce cas, tu vas dans la mauvaise direction. En effet, tu dois considérer plusieurs choses :

• contrôler les données soumises (exemple : données saisie ou pas, si un email est bien un email, etc.)
• différencier sauvegarde et affichage
• • sécuriser la sauvegarde (exemple : éviter les injections SQL)
  • sécuriser l'affichage (exemple : éviter les injections XSS)

Salut,

si je comprends tu veux vérifier le formulaire avant la soumission de celui-ci ?
Si oui tu dois traiter ça directement dans le DOM en js par exemple.
Par exemple créer plusieurs fonctions qui vont par exemple désactiver ton boutton de soumission tant qu'il y a des erreurs (caractères spéciaux, etc) en colorant le input en rouge par exemple.

Puis soumettre pour que ton back sauvegarde.

Mais bon j'ai peut-être pas compris ce que tu voulais ?

oui mais il faut bcp de connaissance en JS pour ca et de code non ?

Honnêtement le plus simple c'est d'utiliser un framework, c'est pas pour rien que tout le monde les utilises ça permet de gagner du temps sur la sécurité, etc...
Regarde du côté de symfony, codeigniter, laravel, f3, etc...

Sinon si tu tiens vraiment à tout faire toi même, regarde du côté de filter_var ( http://php.net/manual/fr/function.filter-var.php ) et filter_input comme dit plus haut, pense aussi a typer tes variables de retours, histoire que tu sois sûr de ce que tu reçois.

et en framework JS?

Le 11 novembre 2018 à 10:29:32 PillsDispenser a écrit :
et en framework JS?

En fait tu as deux types de vérifications :

- Celle front, donc en html5/js. Tu la fait principalement par optimisation pour éviter de solliciter inutilement le serveur si les données récoltées sont fausse.
Par exemple tu un champ "Chaîne youtube" et tu veux que la personne y mettent bien une url Youtube valide.
Dans ce cas c'est facile, tu vas mettre un champ text.
Ensuite en Pré-submit de ton formulaire (c'est un évenement qui se trigger quand l'utilisateur soumet le formulaire) tu vas checker via une Regex par exemple que l'url est valide. Si ce n'est pas le cas tu vas afficher une erreur du style "Le lien de votre chaîne youtube n'est pas valide."
C'est optionnel, mais c'est surtout pratique dans le cas où les données de ton formulaire son soumises en ajax par exemple pour éviter de flooder ton serveur. Et puis la plupart des champs ont déjà une validation HTML avec les input type, y'a que les cas un peu spéciaux comme dans mon exemple à gerer de la sorte.

Cependant il faut pas oublier que les données front sont stockées CHEZ LE CLIENT, et que si il est un peu bidouilleur il peut faire ce qu'il veut de ces données. Par exemple ton champ "Email" il peut modifier le html pour faire sauter la validation et y mettre n'importe quoi. C'est pour cela qu'on dit : "Ne jamais croire les données clients".

- Celle serveur, qui est la VRAI validation. Car si tu enregistre n'importe quoi dans ta BDD tu es à peu près sûr de niquer ton application.
Exemple: Si dans ta base tu as une contrainte d'unicité sur les emails, et que tu n'as pas géré l'exception, eh bien le client va se manger une sale erreur 500.
Du coup ici tu gères tous les cas possibles et tu renvois une erreur sur le champ qui pose problème si il y en a un.

Tu peux ajouter des RegEx en javascript pour controler les champs https://javascript.developpez.com/tutoriels/maitriser-expressions-rationnelles/

Vous êtes parti dans des délires…

PillsDispenser, comme l'a évoqué syndragosa, tu ne dois PAS réduire ton mécanisme de contrôle coté client. Par ailleurs, comme je l'ai fais remarquer, tu dois adapter tes contrôle et le formatage de tes données en fonction du contexte.

Donc :

1. Quand tu contrôle les données, tu tests leur valeur et c'est tout :

Quand tu insères tes données en base, tu n'as pas besoin de transformer les caractères comme "<" en "<" : tu utilises des requêtes préparées et du bind les données utilisateur (cf la doc)

Et pourquoi il faut pas transformé ? J'ai lu la doc.

Point 3 de mon message : tu traites les données quand tu vas les afficher.