Bonjour, je débute sous PHP, s'il vous plait, pouvez-vous me dire ce que chaque ligne de ce code fait ici?

( Jeuxvideo est une table de base de données contenant nom, possesseur, prix ... etc )

http://pastebin.com/F3dmRdmT

Salut !

Attends c'est sérieux ou c'est un troll ? x)

1. On entre dans un bloc try, catch. Cela signifie que toutes les exceptions (erreurs) feront sortir l'exécution dans le bloc catch, et si tout se passe bien tout le bloc try est exécuté.
2. On instancie un objet PDO. C'est une extension PhP permettant de se connecter à une base de données. Ici, on se connecte sur une base MySQL nommée "test" en localhost avec pour identifiants root sans mot de passe (généralement utilisé pour Wampserver).
3. Si une erreur survient (bloc catch) on interrompt le script en affichant une erreur.
4. On effectue une requête ($bdd->query()) SQL et on stocke le statement (objet résultat) dans une variable $reponse.
5. Enfin, pour chaque ligne, on affiche le nom du jeu et son prix en euros puis on retourne à la ligne.
6. On ferme le curseur (instruction inutile dans le cas présent).

Ce code ne doit pas être utilisé en production toutefois x)

Pourquoi pas en prod' ?

A part que la requête n'est pas préparée je vois rien de dramatique

Le 31 juillet 2016 à 10:10:53 Lulla[-]Y a écrit :
Pourquoi pas en prod' ?

A part que la requête n'est pas préparée je vois rien de dramatique

Apprends PHP c'est tout ! OpenClassRoom !

Je suis dév depuis plusieurs années donc j'ai un peu passé le stade d'apprentissage de PHP...
Mais étant de bonne foi j'ai fait un tour sur Open Classroom et ils ont le même code que lui donc bon

Le code du mec vient de openclassroom

Si les données sont sécurisées au moment de l'écriture, elles n'ont pas besoin de l'être lors de la lecture.

Le 04 août 2016 à 11:34:38 lisarael a écrit :
Si les données sont sécurisées au moment de l'écriture, elles n'ont pas besoin de l'être lors de la lecture.

C'est même beaucoup plus sécurisé de le faire en écriture qu'en lecture.

Le 04 août 2016 à 14:17:07 Lulla[-]Y a écrit :

Le 04 août 2016 à 11:34:38 lisarael a écrit :
Si les données sont sécurisées au moment de l'écriture, elles n'ont pas besoin de l'être lors de la lecture.

C'est même beaucoup plus sécurisé de le faire en écriture qu'en lecture.

C'est même pas vraiment une question de sécurité mais de logique, je pensais que c'était implicite dans mon message

Merci d'avoir précisé.

A savoir que si on utilise un filtre comme html entities il faut faire un décode a l'affichage sinon on affichera l'entité html, un truc du genre :& l t ; p & g t ;oui mon poulet & l t ; / p & g t ; ce qui donne en décode :<p> oui mon poulet </p>

Ouep je fais ça quand je stocke des long textes htmls

Pourquoi pas en prod' ?
A part que la requête n'est pas préparée je vois rien de dramatique

Les requêtes préparées ne sont pas utiles dans ce cas de figure.

• Pas de framework, pas de séparation vue / modèle. C'est bien pour de petites applis voire moyennes mais sur de la grosse application c'est imbuvable, de surcroît, lorsqu'on débute, autant commencer avec les bonnes pratiques ;
• Pas de traitement de la sortie avec htmlspecialchars, donc faille XSS ;
• Le "die", ça n'existe pas.
• Le code de connexion à la base de données doit être répété sur chaque fichier, c'est une très mauvaise pratique, préférer un include ;
• Les identifiants de connexion à la base de données sont codés en dur, très mauvaise pratique aussi.

Si les données sont sécurisées au moment de l'écriture, elles n'ont pas besoin de l'être lors de la lecture.

C'est vrai sauf qu'à part pour les éditeurs WYSIWYG, il s'agit d'une mauvaise pratique. Si l'on découvre une faille dans htmlspecialchars, par exemple, la version stockée ne bénéficiera pas de la mise à jour. Alors que si l'on filtre dès l'affichage, le résultat obtenu sera mis à jour en même temps que la fonction qui filtre les données.

C'est même beaucoup plus sécurisé de le faire en écriture qu'en lecture.

Non, justement, c.f mon message du dessus.

C'est même pas vraiment une question de sécurité mais de logique, je pensais que c'était implicite dans mon message

Ça peut économiser du temps de traitement, comme je l'ai dit pour les éditeurs WYSIWYG puisqu'on va filtrer les balises HTML au lieu de les remplacer (white list). De plus sur un forum affichant des 100 aines de messages, oui on verra la différence. Seulement c'est à double tranchant... Il faut faire attention.

A savoir que si on utilise un filtre comme html entities il faut faire un décode a l'affichage sinon on affichera l'entité html

Si tu fais ça, tu retires tout l'avantage de htmlentities, c'est inutile (et c'est une faille de sécurité).
Le but de l'encodage est d'empêcher l'interprétation de code HTML (le rendant ainsi visible), pas de le rendre interprétable ;)

Ouep je fais ça quand je stocke des long textes htmls

Ben tu devrais pas x) Parce qu'en plus ça alourdit le texte (ça rajoute des caractères) et donc ça prendra plus de place en base de données.