Qui peut m'expliquer un peu ce code qui... fonctionne bien

Bonjour,

J'ai un petit bout de code là, qui remplit bien son office.
Mais je ne pige pas bien les différentes étapes. Si quelqu'un veut bien les détailler en bon français, je l'en remercie par avance :

Code:

$sql = "INSERT INTO pmot_clef (libelle,libelle_url) VALUES ('$libelle','$libelle_url')";
$stmt = $dbh->prepare ($sql); /* On prépare la requête */
$stmt->execute();

//on récupère l'id du tuple qui vient d'être créé pour incrémenter le compteur
$nouveau_tuple=$dbh->LastInsertId();

//on incrémente le compteur du nouveau tuple créé
 $sql = "UPDATE mot_clef SET compteur=compteur+1 WHERE id=".$nouveau_tuple."";
 $stmt = $dbh->prepare ($sql); /* On prépare la requête */
 $stmt->execute();
 

Donc ça fonctionne. Mais précisément : pourquoi la valeur de $nouveau_tuple est-elle attribuée via $dbh et non $stmt ?
Ou autrement dit, pourquoi utilise-t'on la fonction LastInsertId() avec $dbh plutôt qu'avec $stmt ?

Merci d'avance

 

Salut à vous et merci pour vos réponses.

Non, ce n'est pas ma question.
Dans cette ligne précise :

Code:

$nouveau_tuple=$dbh->LastInsertId();

Pourquoi n'a-t'on pas plutôt :

Code:

$nouveau_tuple=$stmt->LastInsertId();

Ah bah si, c'est ma question : tu veux dire que la fonction LastInsertedID() est une sorte de requête pré-programmée qui n'a plus besoin que d'appeler les paramètres de la BD, pour être exécutée. Mais comment donc cette fonction peut-elle savoir quelle est la table concernée ?

Je compte ouvrir un topic sur cette fameuse doc' de manière à pouvoir la lire. Il y a des choses que je ne comprends pas dans la présentation, raison pour laquelle je ne m'en sers pas.
Exemple :

Code:

public bool PDOStatement::execute ([ array $input_parameters ] )

Je n'arrive pas à traduire cela en code opérationnel. Qu'est-ce que ce "public bool" ? (souvent on a public string). C'est une présentation formelle de la fonction. Mais je ne sais pas lire ça.

Fais pas dans le suspens spout, c'est pas les oiseaux. Elle est où ici, la fenêtre par laquelle entre les corbeaux ?

 

Hum... Et l'erreur viendrait de la variable $nouveau_tuple, passée en paramètre de recherche ?
Si oui, je n'arrive pas à voir le problème, puisque la valeur de la variable ne provient pas d'une donnée transmise par _GET[] ou $_POST[]. Donc comment pourrait-elle contenir une valeur dangereuse ?
Mais en attendant d'en savoir plus et si le problème vient bien de là, j'imagine que la solution serait alors d'utiliser les requêtes préparées, avec bind_param() ? Si oui, je ne vois pas l'intérêt pour la raison ci-dessus. Ca m'a tout l'air d'alourdir le code d'une ligne de plus (mais mes compétences sont un peu boiteuses, j'en conviens).

 

Salut niap,

Et ce que tu nous dis-là, ce sont des classiques de l'informatique transcendantale, valable pour n'importe quel langage ? Je suis donc supposé apprendre quoi, pour comprendre le manuel PHP ? Les rigueurs théoriques de base de l'informatique, quel que soit le langage ? Genre BTS première année, un truc comme ça ?

 

Ok,

J'm'en vais télécharger quelques docs sur ça, histoire de moins vous prendre la tête...

Merci

 

Oui, mais dans ce cas-là, j'applique une fonction PHP sanitize int sur le tuple récupéré par _GET ou _POST.

Par contre, j'ai trouvé une erreur bizarre, qui ne se produit qu'en localhost.
Voilà : si je fais cela sur mon serveur (OVH mais peu importe je présume) :

Code:

$nouveau_tuple = filter_var($_GET['nouveau_tuple', FILTER_SANITIZE_NUMBER_INT));

Alors, tout fonctionne bien.

Par contre, si je travaille en local (version PHP plus ancienne sans nul doute)
Alors ça me déclenche une erreur me disant que la variable n'est pas initialisée.
Il faut alors que je fasse comme ça

Code:

if(isset($_GET['nouveau_tuple'])) {$nouveau_tuple = filter_var($_GET['nouveau_tuple', FILTER_SANITIZE_NUMBER_INT)); }

La question que je me pose est :
- Faut-il obligatoirement faire de même sur le code en production (sur le serveur OVH) ?
- Et pourquoi n'y-a-t'il pas la même erreur sur celui-ci ?

 

Salut Anonymus, merci pour ta participation.

Ta dernière phrase confirme ma crainte. Là je termine le "gros œuvre", ensuite je verrai pour les questions de sécurité.

Mais en deux mots déjà, histoire de faire avancer un peu le truc. En quoi le fait d'appliquer une fonction sanitize sur une fonction non instanciée génère-t'il une faille de sécurité ? Une variable non instanciée diffère d'une variable avec une valeur nulle, certes, mais pourquoi la fonction sanitize (ou une autre) ne fait-elle pas tout simplement fi de l'opération ?

Il ne me semble pas qu'existait quelques années auparavant, ce problème d'instanciation obligatoire des variables. Je me trompe ?

 

Salut cher Anonymus et merci beaucoup pour ta réponse très complète. J'embraye avec quelques questions supplémentaires, pour préciser un peu la chose, si tu veux bien.

Eh bien, je ne comprends pas bien ce point.
Par exemple, si je fais cela :

Code:

$nouveau_tuple = filter_var($_GET['nouveau_tuple', FILTER_SANITIZE_NUMBER_INT));

Alors j'ai une erreur PHP en local. Cette erreur, je la supprime en ajoutant la condition if ci-dessus.
Partant de là, je ne comprends pas ce que je risque : si la condition if n'est pas vérifiée et bien c'est qu'il n'y a pas de variable $_GET. Donc il ne se passe rien. Et s'il ne se passe rien, un pirate ne peut rien faire avec le rien. Me dis-je.

C'est vrai, je ne suis pas allé chercher jusque là. Ceci dit, ça vaut aussi pour le hacker : va-t'il vérifier chaque matin si le register_globals de mon site est à off ? Enfin en théorie, tu as surement raison.

Code:

if(isset($_GET['nouveau_tuple'])) {$nouveau_tuple = filter_var($_GET['nouveau_tuple', FILTER_SANITIZE_NUMBER_INT)); }
else{$nouveau_tuple =0;}

Oui, mais ça ne me plait pas : parce que maintenant, la variable $nouveau_tuple est créée et cela peut générer l'exécution d'autres conditions par la suite, alors qu'en fait, elle n'est avait pas été réceptionnée par l'URL.

Ok, ça je vais le faire à la fin, quand je repasserai sur la sécurité du site, point par point. Deux précautions valent mieux qu'une, j'en conviens.


Encore merci pour ta réponse, Anonymus. Une reco, une !