Variable php en BDD

[patapon87]

Bonjour

Dans un enregistrement de ma BDD j'ai une ligne avec une variable php dedans.
Par exemple la ligne est "Ce texte est pour $url".
Comment faire pour que lorsque j'exécute / fais un echo de cette ligne, la variable $url soit interprétée et non pas juste affichée ?

En faisant des recheches il semblerait qu'eval() soit la solution ( http://be.php.net/manual/fr/function.eval.php ) mais vivement déconseillé... Avez vous un avis ?


merci !

 

[spout]

Et pourquoi ne pas enregistrer en DB: "Ce texte est pour %s" puis faire un sprintf() ?
Sinon tu px tout simplement faire un str_replace('$url', ...) ainsi pas le danger du eval().

 

[FortTrafic]

En faisant des recheches il semblerait qu'eval() soit la solution ( http://be.php.net/manual/fr/function.eval.php ) mais vivement déconseillé... Avez vous un avis ?

FAUX, elle n'est pas vivement déconseillée dans le cas où tu ne l'utilise pas pour du contenu fourni par les utilisateurs.
Si tu as le contrôle sur les trucs dans la BDD, alors eval n'est absolument pas déconseillé. Nuance de taille !

Par contre oui, un str_replace() ou autre solution donnée fonctionne aussi, pour une fois qu'on a le choix

 

[Blount]

Ouai, et en cas de piratage de la BDD, je te raconte pas le désastre … Je dirais plutôt VRAI, c'est clairement déconseillé.

Franchement, pour ce genre de traitement, rien ne vaut un bon str_replace.
Les cas d'utilisation de "eval" doivent certainement se compter sur les doigts d'une main.

Ma question: pourquoi est-ce stocké sous cette forme en BDD ?

 

[FortTrafic]

Ah ouais et en cas de piratage du serveur alors on est tous morts..
Non mais faut être raisonnable 2 secondes..

Dans ce cas ils ont qu'à retirer la fonction eval() de PHP comme ça c'est moins risqué

Mais oui tout à fait d'accord, moi dans cette situation j'utiliserai simplement str_replace() car c'est la façon la plus simple sans rien changer d'autre. Je n'utilise jamais eval() en fait, non parce que c'est vivement déconseillé, mais parce que je n'en ai pour l'instant jamais eu besoin. Je n'ai jamais besoin de faire des codes complexes non plus...

Je voulais juste faire mon chiant et expliquer que la fonction eval() est seulement vivement déconseillée dans le cas où on ne maîtrise pas ce qu'on lui donne à traiter, c'est tout..

Et d'ailleurs, je n'ai même pas fait le test donc je ne suis pas sûr que eval() fonctionnerait de toutes façons..
Si on a $truc égal à la chaine de caracteres "voilà ma variable $str"
et que
echo $truc;
affiche
voilà ma variable $str

Alors pourquoi est-ce que
eval("echo $truc;");
afficherait autre chose, en remplacant $str par sa valeur ?

Ce n'est pas logique, alors peut être on parle d'une autre utilisation d'eval() et là aucune idée.
D'après l'exemple ils parlent d'utiliser eval pour changer la chaine de caracteres :
eval( "\$truc = \"$truc\";" );
et ensuite de faire un classique
echo $truc;

Donc le danger est inexistant on est d'accord? Quoique le meilleur hacker du monde puisse mettre dans $truc il n'est pas possible de faire quoi que ce soit de dangereux avec un echo $truc; ou un $truc = "$truc";
En tout cas pas plus qu'avec un $truc = str_replace('$str', $str, $truc); qui revient au même..

 

[Blount]

Tu utilises les guillemets pour la chaîne de caractères, donc elle sera évaluée (entendre, variable remplacée) avant d'être passée à eval. Eval recevra bien la chaîne de caractères: voilà ma variable $str

Rien à voir d'être raisonnable ou pas. La réalité est là. L'objectif est d'éliminer les risques. On sait très bien qu'utiliser eval avec une chaîne stockée quelque part (BDD, fichier, etc) est dangereux. Pourquoi en prendre le risque ? Ça peut passer pendant 5 ans, et du jour au lendemain être exploité.
Ici, c'est mettre volontairement en péril son projet.

La fonction eval existe depuis des années. Elle avait peut-être un sens quand PHP était peu évolué. Elle en a peut-être beaucoup moins maintenant.

 

[zeb]

"Ce texte est pour $url".

A la base en effet faut se poser la question de la pertinence de cet enregistrement car si "Ce texte est pour " est une composante fixe elle n'a rien a faire en base et un simple : echo "Ce texte est pour ${url}"; dans le script est suffisant.
Je ne vois d’ailleurs pas a priori l'utilité d'un string replace si $url contiens ce que l'on souhaite.

Pour eval, c'est en effet déconseillé car tu va exécuter sans discernement un code comprenant des variables donc potentiellement un contenu qui n'est pas sous contrôle. Mais il faut savoir que c'est comme les allumettes avec les enfants, on leur défend de les utiliser car c'est dangereux, mais cela rend de bons services dans certains cas comme, par exemple, si la chaîne a traiter par eval contiens des variables qui ne peuvent pas être connues au moment de la composition de la dite chaîne mais qui seront connues lors du traitement.

 

[zeb]

Pourquoi en prendre le risque ? Ça peut passer pendant 5 ans, et du jour au lendemain être exploité.
Ici, c'est mettre volontairement en péril son projet.

Oui mais bon en terme d'échelle de risque, utiliser du code open pour un projet web c'est prendre 100 fois plus de risque que d'utiliser une fonction "dangereuse" avec discernement.
Dans l'exemple que tu donne, la corruption de la BDD n'est pas un exemple probant car a ce stade, tu a d'autre soucis a te faire que de te tracasser pour un eval car le ver est déjà dans le fruit.

 

[patapon87]

Merci pour ces réponses

Alors pour détailler plus je fais une fonction qui selon un paramètre va chercher dans la BDD un swf à charger qui est de type A, B ou C (quelques variantes dans le code).
Pour integrer correctement ce SWF dans le code je dois lui donner une varible $url et je ne vois pas d'autre manière que d'écrire $url dans l'enregistrement SQL et de chercher un moyen de l'appeler par la suite.

Alors effectivement je peux tout à remplacer $url par "patapon" et ensuite faire un str_replace je n'y avais pas pensé.
Je ne vois pas d'autres manières propres de stocker en BDD (pour l'instant je fais tout par elseif et je pense que c'est plus lent et moins flexible)

 

[FortTrafic]

Normalement dans un cas comme ça je pense plutôt que je stockerais dans la BDD le chemin du fichier .swf et ses dimensions si elles ne sont pas tout le temps les mêmes pour tous les fichiers .swf.
Et ensuite dans le code PHP je construit le code HTML pour afficher le .swf, en crééant l'url à partir du chemin et en placant les dimensions width et height au bon endroit dans le code HTML. Et finalement j'insérerai ma variable $str où yen a besoin dans le code HTML.

Je n'irais pas stocker le code HTML pour chaque fichier .swf dans la base de donnée, inutile et surtout j'aime bien garder le minimum en BDD au cas où par exemple il me prend l'envie d'ajouter une ombre portée sous chaque swf ou bien doubler la taille de chaque swf à l'affichage, je peux le faire juste en changeant un truc dans le code PHP et donc sans rien toucher à la BDD..

Mais après il y en a qui peuvent dire qu'ils préfèrent avoir tout dans la BDD et n'avoir qu'à afficher en PHP, que ça consomme moins de CPU à chaque affichage de page..
Oui mais de toutes façons si j'ai un problème de consommation CPU je vais ajouter un systeme de cache de toute la page en une fois, donc le problème de cpu sera réglé encore plus radicalement

 

[Marie-Aude]

Tout à fait d'accord avec FortTraffic
On peut même raffiner en faisant une fonction qui prend comme paramètre les éléments à coder autour de l'url stockée en base de données, et insérer cette fonction dans les templates. Comme ça on a un point unique de modification si on veut changer quoi que ce soit au code.

 

[patapon87]

Ok bon ben je vais essayer comme ca

Merci !