Variable php en BDD

Discussion dans 'Développement d'un site Web ou d'une appli mobile' créé par patapon87, 29 Avril 2014.

  1. patapon87
    patapon87 WRInaute passionné
    Inscrit:
    12 Janvier 2010
    Messages:
    1 135
    J'aime reçus:
    0
    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 !
     
  2. spout
    spout WRInaute accro
    Inscrit:
    14 Mai 2003
    Messages:
    8 913
    J'aime reçus:
    269
    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().
     
  3. FortTrafic
    FortTrafic WRInaute passionné
    Inscrit:
    11 Décembre 2012
    Messages:
    1 210
    J'aime reçus:
    18
    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 :)
     
  4. Blount
    Blount WRInaute impliqué
    Inscrit:
    18 Novembre 2010
    Messages:
    707
    J'aime reçus:
    0
    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 ?
     
  5. FortTrafic
    FortTrafic WRInaute passionné
    Inscrit:
    11 Décembre 2012
    Messages:
    1 210
    J'aime reçus:
    18
    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..
     
  6. Blount
    Blount WRInaute impliqué
    Inscrit:
    18 Novembre 2010
    Messages:
    707
    J'aime reçus:
    0
    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.
     
  7. zeb
    zeb WRInaute accro
    Inscrit:
    5 Décembre 2004
    Messages:
    12 192
    J'aime reçus:
    1
    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.
     
  8. zeb
    zeb WRInaute accro
    Inscrit:
    5 Décembre 2004
    Messages:
    12 192
    J'aime reçus:
    1
    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.
     
  9. patapon87
    patapon87 WRInaute passionné
    Inscrit:
    12 Janvier 2010
    Messages:
    1 135
    J'aime reçus:
    0
    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)
     
  10. FortTrafic
    FortTrafic WRInaute passionné
    Inscrit:
    11 Décembre 2012
    Messages:
    1 210
    J'aime reçus:
    18
    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 :)
     
  11. Marie-Aude
    Marie-Aude WRInaute accro
    Inscrit:
    5 Juin 2006
    Messages:
    16 368
    J'aime reçus:
    2
    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.
     
  12. patapon87
    patapon87 WRInaute passionné
    Inscrit:
    12 Janvier 2010
    Messages:
    1 135
    J'aime reçus:
    0
    Ok bon ben je vais essayer comme ca :)

    Merci !
     
Chargement...
Similar Threads - Variable php BDD Forum Date
Stocker dans des variables php les fonctions MySql Développement d'un site Web ou d'une appli mobile 2 Février 2019
Passer une variable JS vers PHP Développement d'un site Web ou d'une appli mobile 25 Septembre 2018
Protection variable php contre les injections ? Développement d'un site Web ou d'une appli mobile 5 Avril 2016
Var js vers une variable php Développement d'un site Web ou d'une appli mobile 30 Décembre 2014
Faire fonctionner une variable phpbb en php Développement d'un site Web ou d'une appli mobile 27 Mars 2014
Redirection htaccess d'une anciene url php avec variable vers le domaine de base URL Rewriting et .htaccess 19 Février 2014
Utilisation variable php dans du htaccess URL Rewriting et .htaccess 14 Juin 2013
Variable phpsessid s'ajoute automatiquement aux liens ! Développement d'un site Web ou d'une appli mobile 14 Mai 2013
Url rewriting avec une variable PHP URL Rewriting et .htaccess 9 Janvier 2013
php 5.3.8 problème de variable avec setcookie Développement d'un site Web ou d'une appli mobile 13 Avril 2012
  1. Ce site utilise des cookies. En continuant à utiliser ce site, vous acceptez l'utilisation des cookies.
    Rejeter la notice