Bonjour,

J'ai besoin d'etre rassuré, je suis à 2 doigts de pleurer... je vous explique :

Après avoir passé beaucoup de temps à faire un site en PHP, et notamment sur les contrôles de vraisemblances des champs d'un formulaire écris ensuite en BDD, je viens d'essayer l'outil de développement web appelé « F12 »  et là je vois que j'ai accès aux _POST de mon formulaire en envoi pour écriture en BDD et c'est la ma surprise, que je peux modifier les valeurs et  que ça va prendre ces valeurs modifiées et les ecrire en BDD... 

Je suis en localhost, pas testé en réel.

Dites moi que je rêve où que quelque chose m'échappe ??

Bonjour, les outils de développement peuvent modifier tout ce que le navigateur reçoit, c à d le HTML, CSS, JS. En aucune façon il ne peut modifier le PHP qui lui est coté serveur.

C'est à vous de contrôler coté serveur, (et si possible coté navigateur en plus pour éviter de transmettre des données non valide au serveur) la cohérence des données que l'internaute peut transmettre à votre script de traitement. Si vous attendez un nombre c'est à contrôler, à t-il un minimum ou un maximum à ne pas dépasser. Une adresse mail à t-elle le bon format. Une chaine de caractère, outre sa longueur min et max, peut elle avoir des caractères autre que des lettres ou chiffres?  Si des champs sont requis, vérifier que ceux-ci ne sont pas vide. Etc....

Le formulaire d'une page web peut être copier en local, modifier et servir à l'envoie de données à votre script de traitement. Ou l'usage d'un programme, en python par ex., pour  effectuer l'envoie de données.

>> J'ai besoin d'etre rassuré, je suis à 2 doigts de pleurer...

Sur quoi exactement, qu'est ce qui pose soucis?

Merci pour votre réponse.

J'explique : j'ai sur une page un formulaire de saisie sur lequel j'effectue tous les contrôles (en PHP), et lorsque l'utilisateur  clique sur le bouton valider j'appelle la page de mise à jour de la BDD en lui transmettant les données par les _POST, donc sur cette nouvelle page je ne pensais pas refaire les contrôles. Mais l'outils de développement permet de modifier la valeur des _POST et là tout s'écroule...

Quand vous parlez de "_POST"  Vous parlez de la variable $_POST ou de l'entête HTTP _POST?  Je comprends que vous parlez de l’entête HTTP.

>> lorsque l'utilisateur  clique sur le bouton valider j'appelle la page de mise à jour de la BDD en lui transmettant les données par les _POST,

Au clique sur le bouton d'un formulaire les données de ce formulaire sont envoyées au script de traitement de ce formulaire, c'est peut être ce que vous appelez  "la page de mise à jour de la BDD"? C'est  ce script de traitement qui doit :

1. Vérifier la cohérence des informations transmise, 
2. Transmettre, en cas de succès du point 1 uniquement, les données en base.

Je ne situe pas bien le problème, si vous voulez vous pouvez me transmette en fichier .zip les pages concernées ainsi que la structure de la db pour que je regarde le code.

  Quel est exactement la modification que vous faite avec les outils de développement? C'est dans l'onglet réseau -> Nouvelle requête?

Oui je parle de la variable $_POST,  effectivement ce que  j'appelle "la page de mise à jour de la BDD" est bien le script de traitement de ce formulaire (j'appelle ça une page car c'est un fichier PHP et j'entend tout le monde dire 'page').

J'ai donc un fichier, par exemple 'formulaire.php', avec mon formulaire et les "_POST" correspondants ($_POST['email'] par exemple), dans lequel j'effectue tous les contrôles, et au clic du bouton 'submit' j'appelle le 'script' de traitement de ce formulaire (par exemple 'traitement.php') qui se charge de transmettre les données en base. Je ne 'refait' donc pas de contrôle dans ce script. 

Quand on est encore sur la page 'formulaire.php' avant de cliquer sur le bouton valider, on peut modifier la valeur dans l'outil de développement 'F12' (de Chrome), dans l'onglet 'éléments', où l'on voit le code HTML, par exemple '<form action=...', ensuite "<input type=hidden name=email value='"toto@gmail.com'>" (ici on peut modifier toto en titi).

Pour la petite histoire je fait tous les contrôles dans la page 'formulaire.php' car en les faisant dans la page 'traitement.php', en cas d'erreur il faut revenir à la page précédente et là problème, le navigateur demande confirmation (renvoyer le contenu d'un formulaire ...).

Bonjour, je comprends mieux, vous parlez de la modification des éléments HTML via l'inspecteur des éléments et pas de l’envoie du formulaire par un autre moyen que le formulaire HTML lui même. Désolé pour ma méprise.

Réaliser le traitement dans le même fichier que le formulaire HTML (soit 'formulaire.php') n'est pas un problème. Comme vous l'avez constaté tout élément HTML peut être modifier, il n'est dés lors pas recommandé d'utiliser une balise HTML pour transmettre des informations cachées car elle ne le sont pas du tout. 

Si vous devez passer au formulaire des informations cachées, ou de page en page, les sessions PHP sont toutes indiquées pour cela. Je ne connais pas la raison qui vous pousse à passer une adresse mail dans un input type="hidden" mais si cela concerne l'identité d'un utilisateur on utilisera plutôt son identifiant que vous avez garder en session lors de sa connexion .

Plus d'info sur les sessions PHP :

• https://www.php.net/manual/fr/reserved.variables.session.php
• https://www.php.net/manual/fr/session.examples.basic.php
• https://www.pierre-giraud.com/php-mysql-apprendre-coder-cours/session-definition-utilisation/
• https://openclassrooms.com/fr/courses/918836-concevez-votre-site-web-avec-php-et-mysql/4239476-conservez-des-donnees-grace-aux-sessions-et-aux-cookies

-
Edité par AbcAbc6 25 avril 2023 à 12:55:46

Pour moi, les vérifications se font essentiellement lors du traitement juste avant l'envoie en BDD (après le submit), peu sur le formulaire directement (le formulaire doit guider le type de saisie. Et pour l'insertion en BDD, on passe par des requêtes préparées

Bonjour,

Merci du temps que vous m'accordez.

Effectivement, après votre éclairage je constate le phénomène !! 

Je n'avais jamais fait attention à ça et donc ça remet tout en cause. En fait, d'après  tout ce que j'ai pu voir sur le net, les données du formulaire sont envoyées par $_POST au script de traitement mais les contrôles sont effectués dans ce même script, donc dans ce script il n'y a pas d'HTML et donc on ne voit pas les $_POST.

Pour le "input type="hidden" c'est parce que j'ai enchainé un autre formulaire de 'seconde validation' et je renvois donc les $_POST en hidden...

Comme je l'ai indiqué, je fait tous les contrôles dans la page 'formulaire.php' car en les faisant dans la page 'traitement.php', en cas d'erreur il faut revenir à la page précédente et là problème, le navigateur demande confirmation (renvoyer le contenu d'un formulaire ...).

Pourriez-vous m'indiquer brièvement quelle méthode et technique appliquer pour repondre, toute sécurité, à mon besoin décrit ci-dessous :

- Un premier formulaire avec  des cases à cocher qui vont conditionner les champs à saisir du formulaire suivant

- Un second formulaire avec des champs à saisir, et un bouton 'valider' et un bouton  'abandonner'

- Un contrôle de vraisemblance de tous les champs, avec affichage des anomalies et retour au formulaire dans ce cas

- Si contrôles OK, affichage d'une synthèse des éléments saisie avec en plus, des éléments calculés (prix en fonction de ce qui est saisie..) et un bouton 'valider' et un bouton 'retour au formulaire de saisie' et un bouton  'abandonner'.

- Si 'validation'  :  paiement, et, si paiement accepté, écriture en base.

-----------------------------------------

Voilà, j'avoue ne pas savoir comment imbriquer tout çà.. et ne pas avoir de message du navigateur demandant de confirmation l'envoi du formulaire.

Bonjour Umfred,

C'est ce que j'avais fait avant mais j'ai fait cette autre méthode car en cas d'erreur il faut revenir à la page précédente et là problème, le navigateur demande confirmation (renvoyer le contenu d'un formulaire ...).

Qu'entendez vous par 'requêtes préparées' ? j'ai déjà entendu ça sans comprendre, moi je 'construit"' la requête dans le script en fonction des information reçues. 

-
Edité par JeanAimarre11 25 avril 2023 à 15:43:44

une requête préparée est une requête qui n'est pas écrite en concaténant les variables dans la requête => https://www.w3schools.com/php/php_mysql_prepared_statements.asp 

OK j'ai compris le principe, ça semble intéressant notamment contre les injections SQL.

Il faudra que je regarde ça de près car il faut bien saisir les subtilités avant la mise en œuvre.

Quitte à modifier mon code d'après vous qu'est-il le mieux à utiliser ? Mysqli/PDO, Style orienté objet/Style procédural ? 

Je me demande si tu n'aurais pas de meilleures réponses en faisant déplacer le sujet dans la rubrique PHP du forum (partie développement web) (en faisant une demande à un modo)

Bonjour,

Ce que vous réalisez est un tunnel d'achat/vente/conversion. Avec ces termes vous pourrez sans doute mieux cibler vos recherches. Personnellement je ne le ferais pas au départ de rien, mais utiliserais des outils/framework pour m’appuyer sur quelque chose de déjà développer, tester, et robuste.

   Je pense que cela serait plus facile de développer en  Style orienté objet, si vous en avez la connaissance. J'ai une préférence pour PDO pour sa syntaxe plus facile à mon gout et la possibilité avec ce driver de pouvoir changer de base de donnée sans modification du code. Bien sur cela n'est qu'une préférence personnelle on peut tout aussi bien utiliser  Mysqli.

umfred a écrit:

Je me demande si tu n'aurais pas de meilleures réponses en faisant déplacer le sujet dans la rubrique PHP du forum (partie développement web) (en faisant une demande à un modo)

Avant de déplacer le sujet (j'y ai pensé), j'attendais de voir si le PO allait poster du code ou rester dans une certaine généralité. 

Bonjour,

C'est moi qui suis dans le tunnel..

En fait je suis parti d'une application existante (de 2008) il y a plus de 10 ans que j'avais pas mal modifiée à l'époque, j'avais abandonné, et je viens de m'y remettre, je voudrais seulement la faire fonctionner à minima et si le site à du 'public' je ferais (ou ferais faire) une nouvelle application au gout du jour.

Merci pour tous vos conseils, ça m'a donné matière à réfléchir.

PS : c'est quoi le 'PO' ?

PO = posteur originel = celui qui a créé le sujet