addslashes, mysql_real_escape_string, htmlentities ?

quels méthode utilisé vous pour traiter vos données d'insertions ?

  • Addslashes

    Votes: 0 0.0%
  • Mysql_real_escape_string

    Votes: 0 0.0%
  • Htmlentities

    Votes: 0 0.0%
  • Autres...

    Votes: 0 0.0%

  • Total voters
    0
WRInaute occasionnel
Bonjour à vous, dans le cadre d'une insertion dans une base de données, quels méthode utilisé vous pour traiter vos données d'insertions ?

Si vous en avez d'autre, merci de me le signaler et de me donner leur avantage, pareils si elles sont couplés ;)
 
WRInaute impliqué
Je n'utilise pas :
* addslashes : certains caractères pouvant être dangereux ne sont pas échappés avec cette fonction.
* htmlentities : la pire des fonctions !! Elle ne sert strictement à rien mise à part pourrir les données de la base.

Donc, résultat, mysql_real_escape_string suffit amplement.
 
WRInaute occasionnel
OK, mais par exemple je rentre une valeur
"> ICI JE FAIS CE QUE JE VEUX

dans un input de formulaire, quand je vais afficher cette variable en value" " ca va me fermer le formulaire et m'afficher ce que je veux, comment fais tu pour contrer les effets de quote ?
 
WRInaute accro
A l'enregistrement en DB, comme Blount : mysql_real_escape_string()
A l'affichage en value="" => htmlentities()
 
WRInaute impliqué
Attention, je n'ai jamais dit qu'il ne fallait pas utiliser "htmlentities", la question du sondage concerne l'insertion dans la base de données, et non pas l'affichage des données.

En effet, il faut toujours protéger les chaînes de caractères lors de l'affichage. Pour cela, j'utilise la fonction "htmlspecialchars".

Mais lors de l'insertion en base de données, aucun traitement de ce genre ne doit être fait.
 
WRInaute passionné
Blount a dit:
Attention, je n'ai jamais dit qu'il ne fallait pas utiliser "htmlentities", la question du sondage concerne l'insertion dans la base de données, et non pas l'affichage des données.

En effet, il faut toujours protéger les chaînes de caractères lors de l'affichage. Pour cela, j'utilise la fonction "htmlspecialchars".

Mais lors de l'insertion en base de données, aucun traitement de ce genre ne doit être fait.
d'un coté optimisation, mieux vaut faire le htmlentities (ou special char) une fois a l'insertion que des milliers de fois (voir des millions) à l'affichage pendant des jours, des mois, des années...

Aprés chacun sa philosophie ...
 
WRInaute occasionnel
Donc forummp3 tu utiliserais un truc comme ca : htmlentities(mysql_real_escape_string($variable_insertion); ?
 
WRInaute impliqué
forummp3 a dit:
Blount a dit:
Attention, je n'ai jamais dit qu'il ne fallait pas utiliser "htmlentities", la question du sondage concerne l'insertion dans la base de données, et non pas l'affichage des données.

En effet, il faut toujours protéger les chaînes de caractères lors de l'affichage. Pour cela, j'utilise la fonction "htmlspecialchars".

Mais lors de l'insertion en base de données, aucun traitement de ce genre ne doit être fait.
d'un coté optimisation, mieux vaut faire le htmlentities (ou special char) une fois a l'insertion que des milliers de fois (voir des millions) à l'affichage pendant des jours, des mois, des années...

Aprés chacun sa philosophie ...

Sauf que là, ce n'est plus le même sujet.
Ce dont tu parles, c'est un système de cache.

Une base de données n'est pas une page HTML.
À tout moment d'un projet, il peut peut-être nécessaire de créer une application exploitant la base de données sans même afficher de l'HTML. À ce moment là, tu te retrouveras à traiter des données erronées.

Et j'ai un gros doute sur les impacts sur la performance de l'utilisation de la fonction à chaque affichage.
 
WRInaute accro
Si c'est pour une application HTML ou pas, enregistrer les entités en HTML en BDD n'est pas une bonne technique.
C'est à l'affichage qu'il faut faire le htmlentities/htmlspecialchars.
 
WRInaute occasionnel
Donc je récapitule ce qui vous semble le mieux et le plus adéquate ?

INSERTION : mysql_real_escape_string();
AFFICHAGE : htmlentities/htmlspecialchars
 
WRInaute impliqué
forummp3 a dit:
oui, enfin, là sa question est en rapport avec php, donc j'imagine que c'est pour un site, donc du html.

Tu sais qu'il n'y a pas que PHP dans la vie. Il ne parle pas d'une application tournant entièrement avec PHP. Et si même était le cas, il faut toujours voir à long terme.

Java, Python, Perl, C, C++, tout autant de langage utilisable pour concevoir des applications web.
Et tout autant de langage pouvant utiliser simultanément la base de données, peu importe ce qu'il est fait des données.

Après, vous faites ce que vous voulez, mais bon, j'espère ne jamais à devoir repasser derrière vous …
 
Nouveau WRInaute
Bonjour,
Je suis désolé de déterrer un vieux sujet comme celui-ci mais je ne trouve pas de réponse satisfaisante.

Mon problème est lié aux guillemets et à mysql.
J'utilise
Code:
mysql_real_escape_string
pour faire mes inserts dans ma DB. Et lorsque j'insère du texte avec des " il me stock des "
Déjà est-ce normal ?

C'est à l'affichage que j'ai ensuite des soucis. Pour éviter les failles XSS, j'utilise htmlentities.
Sauf que htmlentities sur du texte contenant des " bah ça ne fonctionne pas très bien :)

Pour résoudre ce problème je peux faire ça :
Code:
htmlentities(html_entity_decode("mon texte avec des ""))
Mais c'est crade non ? Ce sont deux fonctions inverses.

Est-ce que quelqu'un peut me dire où se situe mon problème ?
Merci.
 
WRInaute impliqué
oups, j'ai lu trop vite :
"mysql_real_escape_string() appelle la fonction mysql_escape_string() de la bibliothèque MySQL qui ajoute un anti-slash aux caractères suivants : NULL, \x00, \n, \r, \, ', " et \x1a. "

donc "j'insère du texte avec des " il me stock des " " est faux, s'il y a des """, c'est que ce n'est pas mysql_real_escape_string qui a été utilisé.
 
WRInaute impliqué
Il ne faut pas utiliser htmlentities pour l'affichage mais htmlspecialchars.
Il faut revoir ta façon d'insérer en base de données. À mon avis, il n'y a pas que mysql_real_escape_string d'utilisé, car ce dernier n'applique pas de conversion de chaîne (ex: ' en ") mais de la protection de chaîne.
 
Discussions similaires
Haut