Salut à vous
j’aimerais afin d'affiner mes connaissances, savoir plusieurs choses sur le PDO.
Si je fait plusieurs requêtes à la suite, et que à chaque fois je met $query=$cnx->prepare('....'), y a t'il un risque que les variables $query s’emmêlent?
Est il nécessaire à chaque fin de requête de fermer avec $query->CloseCursor();, ou peut on le faire en bas de page?
Est il toujours conseiller de mettre htmlspecialchar() lors de l'affichage des données récupérées via requêtes sql en PDO?
Je sais que ça peux paraitre bête, mais malgré tous les tutos sur le PDO, j'ai pas trouver de réponses concrètes à cela, et dans un soucis de perfectionnement, j'aimerais le savoir ^^
Merci de votre aide
Cordialement
la communauté d'entraide francophone dédiée au PHP
[RESOLU] Petites questions PDO
Salut,
1/ oui : à chaque $query= ... Tu écrase la valeur précédente donc sauf si tu a récupéré le jeux de résultat complet avant ça met le brin. Après faut voir un exemple de code pour être plus précis
2/ oui c'est préférable sinon y a un risque d'emmelage mais globalement ça ce démerde pas trop mal et beaucoup l'oublie sans soucis.
3/ oui pdo ne fait que t'aider à récupérer des données mais ne les mets pas en forme. Htmlspecialchars ou htmlentities permettent d'éviter toute interprétation du html qui pourrais être contenu dans la base donc pdo ou pas c'est indispensable
Y a pas questions bêtes on peux pas tout deviner
@+
1/ oui : à chaque $query= ... Tu écrase la valeur précédente donc sauf si tu a récupéré le jeux de résultat complet avant ça met le brin. Après faut voir un exemple de code pour être plus précis
2/ oui c'est préférable sinon y a un risque d'emmelage mais globalement ça ce démerde pas trop mal et beaucoup l'oublie sans soucis.
3/ oui pdo ne fait que t'aider à récupérer des données mais ne les mets pas en forme. Htmlspecialchars ou htmlentities permettent d'éviter toute interprétation du html qui pourrais être contenu dans la base donc pdo ou pas c'est indispensable
Y a pas questions bêtes on peux pas tout deviner
@+
Il en faut peu pour être heureux ......
Merci à toi
Par contre j'ai ouïe dire que PDO sécurise les insertion en BdD, peux tu confirmer cela, et éventuellement m'en dire plus?
En tout cas je suis sur d'une chose, j'aime la PDO ^^, une fois bien compris c'est excellent et propre ^^
Merci de votre aide
Cordialement
Par contre j'ai ouïe dire que PDO sécurise les insertion en BdD, peux tu confirmer cela, et éventuellement m'en dire plus?
En tout cas je suis sur d'une chose, j'aime la PDO ^^, une fois bien compris c'est excellent et propre ^^
Merci de votre aide
Cordialement
C'est le principe des requêtes préparées.
La requête est compilée par le SGBD, puis elle est exécutée comme une fonction avec paramètres.
Ce qui empêche toute injection.
A noter que les fonctions suivantes ne sont pas protégées contre l'injection :
PDO::query($sql)
PDO::exec($sql)
Il faut donc protéger soit même les variables injectées avec PDO::quote().
La requête est compilée par le SGBD, puis elle est exécutée comme une fonction avec paramètres.
Ce qui empêche toute injection.
A noter que les fonctions suivantes ne sont pas protégées contre l'injection :
PDO::query($sql)
PDO::exec($sql)
Il faut donc protéger soit même les variables injectées avec PDO::quote().
STOP les requêtes préparées ne protège RIEN DU TOUT c'est simplement que le mécanisme de requête préparée de PDO le fait mais si tu test la méthode en console tu peux la vautrer.
C'est une belle ânerie que tout le monde indique PDO ça fait tout, NON !
Et les requêtes préparées c'est pas utiliser a tout bout de champs. Elles sont prévue pour une réutilisation des requetes. j'ajoute que (au moins dans le cadre des tests que j'ai fait sur mysql) elles sont lié à une session, donc une requête préparée pour sortir une connexion ou un liste de news c'est de la connerie (je ne vois rien d'autre a moins que vous allier faire les cours d'une semaine avec un semi-remorque, pour 2 max hein).
si tu fait un traitement "par lot" alors la oui tu va l'utiliser et avoir un gain de perf, en one shot c'est inutile !
@+
C'est une belle ânerie que tout le monde indique PDO ça fait tout, NON !
Et les requêtes préparées c'est pas utiliser a tout bout de champs. Elles sont prévue pour une réutilisation des requetes. j'ajoute que (au moins dans le cadre des tests que j'ai fait sur mysql) elles sont lié à une session, donc une requête préparée pour sortir une connexion ou un liste de news c'est de la connerie (je ne vois rien d'autre a moins que vous allier faire les cours d'une semaine avec un semi-remorque, pour 2 max hein).
si tu fait un traitement "par lot" alors la oui tu va l'utiliser et avoir un gain de perf, en one shot c'est inutile !
@+
Il en faut peu pour être heureux ......
moogli, peux tu me montrer comment utiliser PDO sans préparer la requête stp?
Mais une question me trotte dans la tête, est fiable PDO ou doit on rajouter une sécurité supplémentaire?
Et comment puis je tester d'éventuelles injections sql, afin de déterminer si mes requêtes sont sécurisées ou pas?
Merci de votre aide en tout cas, j'éspére un jours arriver à être plus serin quand à la gestion des sécurités. (y a pas vraiment d'éspoire en ça mais bon ^^)
Mais une question me trotte dans la tête, est fiable PDO ou doit on rajouter une sécurité supplémentaire?
Et comment puis je tester d'éventuelles injections sql, afin de déterminer si mes requêtes sont sécurisées ou pas?
Merci de votre aide en tout cas, j'éspére un jours arriver à être plus serin quand à la gestion des sécurités. (y a pas vraiment d'éspoire en ça mais bon ^^)
@xTG : essai en console avec une chaîne que tu mettrais pour une injection, y a des chances que ça se vautre. (mais c'est les cours où l'on met un cast de bœuf dans un try catch pour vérifier que l'on a saisie un nombre, sinon ben on met un message d'erreur de compte dans l'exception => c'est pas propre 
).
Une requête 'normale' => query + quote
Pour le reste faut demander à Google "injecton SQL" tu peux, dans le même genre lui demander "faille xss" pour info
Sinon en rapide, par exemple sur un formulaire de login, tu rentre dans le premier champ un truc valable (genre pseudo d'un admin) et en mot de passe un truc genre ' or 1=1;--
Et tu regarde ce que ça donne
@+
). Une requête 'normale' => query + quote
Pour le reste faut demander à Google "injecton SQL" tu peux, dans le même genre lui demander "faille xss" pour info
Sinon en rapide, par exemple sur un formulaire de login, tu rentre dans le premier champ un truc valable (genre pseudo d'un admin) et en mot de passe un truc genre ' or 1=1;--
Et tu regarde ce que ça donne
@+
Il en faut peu pour être heureux ......
Avec une requête préparée en console cela n'arrivera pas. Si tu ne comprends pas je t'invite à relire mon message.@xTG : essai en console avec une chaîne que tu mettrais pour une injection, y a des chances que ça se vautre. (mais c'est les cours où l'on met un cast de bœuf dans un try catch pour vérifier que l'on a saisie un nombre, sinon ben on met un message d'erreur de compte dans l'exception => c'est pas propre
Je n'ai jamais parlé de requête non préparée et c'est là toute la différence entre compilation avec ou sans arguments.
Après si tu argumentes sur la possibilité d'utiliser la préparation de requête logicielle de l'interface PDO...
Je dirai qu'elle reste un moindre mal pour les SGBD qui ne disposent pas de la possibilité de gérer cela.
Mais pour ma part, je suis un grand partisan du query() + quote(), au moins on sait ce que l'on fait et si ça se vautre on pourra se le reprocher.
