[PHP-JS] htmlentities ne fonctionne pas après str_replace

Bonjour
Je ne comprend rien à mon script : il fonctionne, mais c'est illogique ou en tout cas je ne comprend pas quelque chose.

Voilà :
Je reçois des données d'un formulaire, je filtre :

Code:

---

1 2 3

$contenu=htmlentities($_POST['contenu']); $contenu=stripslashes($contenu);

---

Comme c'est pour un éditeur de texte, je remplace le bbCode maison par du html :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

$contenu=nl2br($contenu); $contenu=str_replace("&lt;br /&gt;", "<br>", "$contenu"); //idem pour la balise en gras $contenu=str_replace("", "<b>", "$contenu"); $contenu=str_replace("", "</b>", "$contenu"); //idem pour l'italique $contenu=str_replace("", "<i>", "$contenu"); $contenu=str_replace("", "</i>", "$contenu"); //idem pour les citations (l'espace entre" et > dans la div permet de le distinguer du "> pour les liens juste en dessous ( je sais c'est foireux, mais ça fonctionne, donc en attendant...) $contenu=str_replace("[citer]", "<br><b>citation:</b><br><div class=\"citer\">", "$contenu"); $contenu=str_replace("[/citer]", "</div>", "$contenu"); //idem pour les liens (on prend en compte la répétition des http et la position des deux premières lignes doit etre conservées $contenu=str_replace("[a=&quot;http://", "<a href=\"http://", "$contenu"); $contenu=str_replace("[a=&quot;", "<a href=\"http://", "$contenu"); $contenu=str_replace("&quot;]", "\"target=\"_blank\"\">", "$contenu"); $contenu=str_replace("[/a]", "</a>", "$contenu");

---

Ensuite comme j'envoie le contenu dans un champ hidden je le refiltre comme ça :

Code:

---

$contenu=htmlentities($contenu);

---

Si je ne filtre pas ainsi juste à la fin, ça s'affiche dans la page et ça foire.

Ensuite j'envoie dans la base et je ne filtre PLUS RIEN à l'exception d'un mysql_real_escape_string qui n'a pas de rapport ici.

Alors ma question :
Puisque je fais un $contenu=htmlentities($contenu) en bout de course, comment ce fait-il que les balises html créées par les str_replace ne soit pas désactivées, alors que les autres caractères spéciaux, par exemle &<, le sont ?
Car je le répète tout s'affiche bien, mais quand j'ai fait ça j'ai du le faire au petit bonheur la chance et là je ne pige plus du tout.

Merci pour vos explications si vous en avez.

Je viens de revérifier, effectivement les caractères spéciaux sont bien codés lors de l'affichage, mais ceux issus des_strreplaces qui s'affichent tel quel.
A croire que le htmlentitites effectués à la fin ne s'applique pas aux balises issues du str_replace, qui pourtant est effectué avant.

Qui peut m'expliquer cela ?

Salut

Mise au point : htmlentities() ne permet pas de filtrer mais de convertir.
Tu ne devrais pas l'utiliser pour les données entrantes mais plutôt (et uniquement) pour les données à afficher (dans le navigateur, pas dans la base de données).
Du coup, ta solution pour filtrer n'est pas adaptée.

En fait je préfère filtrer (convertir si tu préfère) AVANT parce que si je converti avant l'insertion je le fait une fois, si je converti à l'affichage je le fais xxx fois.
C'est donc un énorme gain de temps il me semble.

Par contre pour mon script, qui je l'ai dit fonctionne très bien au demeurant même si je ne comprend pas, j'ai fait quelques tests et j'ai constaté cela, c'est bizarre :

je converti par htmlentities la balise <w> une seule fois avant l'insertion dans un champ hidden.
Il y est écrit, lorsque je regarde le code source :
&lt;w&gt;
Par contre dans la base il arrive sous cette forme <w> et ne s'affiche donc pas dans la page.
Or il n'y aucune fonction de conversion entre l'insertion dans le champ hidden, sous la forme &lt;w&gt; suite à la conversion par htmlentities et le moment de l'insertion dans la base, ou l'on retrouve <w>...

C'est ça que je ne pige pas, parce que si je fais deux fois htmlentities avant l'insertion dans le champ hidden, il y a écrit dans celui-ci :
&amp;lt;w&amp;gt;, le & de &lt; étant à son tour convertie en &amp;.
Mais cette fois dans la base on retrouve &lt; et non &amp;lt;.

Il y a donc une conversion automatique qui se fait entre l'input hidden et l'insertion dans la base, mais je le répète parce que j'ai bien vérifié, elle n'est pas de moi, je ne reconverti/filtre pas entre l'insertion dans le input hidden et l'insertion dans la base.

Voilà j'espère être assez clair en tout cas j'aimerais bien comprendre le mécanisme.

Citation:

---

C'est donc un énorme gain de temps il me semble.

---

Sauf que :
- tu ne pourras plus faire de recherche dans ta base, MySQL étant incapable de décoder ce bazar
- si tu veux un jour utiliser ces données pour autre chose que HTML (XHTML, XML, Javascript, CSV, XLS, PDF, ou autre), tu risques d'avoir de gros soucis

Citation:

---

tu ne pourras plus faire de recherche dans ta base, MySQL étant incapable de décoder ce bazar

---

Pour le moment ça ne me pose pas de problème, je convertie le mot à aller chercher et puis il trouve son équivalent convertie dans la base.

Citation:

---

si tu veux un jour utiliser ces données pour autre chose que HTML (XHTML, XML, Javascript, CSV, XLS, PDF, ou autre), tu risques d'avoir de gros soucis

---

On me l'a déjà sorti aussi mais pour le moment ça n'est pas le problème et de toute façon un str_replace pour tout reconvertir ça prend 5 minutes et là aussi ça ne se fait qu'une fois en cas de besoin, au lieu de le faire à chaque affichage.
Donc ça c'est de la pure théorie, mais en pratique, concrètement, ma solution est quand même plus rapide, nonobstant les dits problèmes théoriques.
Pour le moment, aucun argument ne m'a fait changé d'avis sur ce point, mais bon pourquoi pas, je suis pas borné non plus.


Par contre pour le problème de l'encodage automatique des caractères spéciaux comme expliqué, pas forcément très bien, dans mon post au dessus, vous en pensez quoi ?

Citation:

---

je converti par htmlentities la balise <w> une seule fois avant l'insertion dans un champ hidden.
Il y est écrit, lorsque je regarde le code source :
&lt;w&gt;
Par contre dans la base il arrive sous cette forme <w> et ne s'affiche donc pas dans la page.
Or il n'y aucune fonction de conversion entre l'insertion dans le champ hidden, sous la forme &lt;w&gt; suite à la conversion par htmlentities et le moment de l'insertion dans la base, ou l'on retrouve <w>...

---

Citation:

---

Envoyé par psychoBob

Pour le moment ça ne me pose pas de problème, je convertie le mot à aller chercher et puis il trouve son équivalent convertie dans la base.

---

tu perds les avantages de MySQL, comme la correspondance des accents...

Citation:

---

On me l'a déjà sorti aussi mais pour le moment ça n'est pas le problème et de toute façon un str_replace pour tout reconvertir ça prend 5 minutes et là aussi ça ne se fait qu'une fois en cas de besoin, au lieu de le faire à chaque affichage.
Donc ça c'est de la pure théorie, mais en pratique, concrètement, ma solution est quand même plus rapide, nonobstant les dits problèmes théoriques.
Pour le moment, aucun argument ne m'a fait changé d'avis sur ce point, mais bon pourquoi pas, je suis pas borné non plus.

---

Un export PDF ça peut être long à faire, alors s'il faut d'abord se tapper une conversion HTML => brut, ça va être beau.

Honnêtement, le htmlspecialchars() (car htmlentities() n'est pas vraiment utile) est très rapide, et je pense honnêtement que ce n'est pas là dessus que tu gagneras en performances.

Il y a bien plus à faire sur un site pour réellement gagner en performances (comme gèrer le cache HTTP par exemple).
D'autant plus quand on voit qu'a coté tu n'hesites pas à modifier des pseudos identifiants de sessions en base de données à chaque hit HTTP...

Citation:

---

Par contre pour le problème de l'encodage automatique des caractères spéciaux comme expliqué, pas forcément très bien, dans mon post au dessus, vous en pensez quoi ?

---

t'es sûr de ne pas avoir un htmlentities() ou htmlspecialchars() à l'affichage également ? Quand tu dis dans la base il y a "<w>", comment le sais tu ? comment vérifies tu ?

Citation:

---

tu perds les avantages de MySQL, comme la correspondance des accents...

---

ça pose aussi des problèmes sur certaines versions il me semble.

Citation:

---

Honnêtement, le htmlspecialchars() (car htmlentities() n'est pas vraiment utile) est très rapide, et je pense honnêtement que ce n'est pas là dessus que tu gagneras en performances.

---

oui d'ailleur j'utilise de plus en plus htmlspecialchars.

Citation:

---

Il y a bien plus à faire sur un site pour réellement gagner en performances (comme gèrer le cache HTTP par exemple).

---

j'ai déjà lu ça mais ça me parle autant que du chinois.

Citation:

---

D'autant plus quand on voit qu'a coté tu n'hesites pas à modifier des pseudos identifiants de sessions en base de données à chaque hit HTTP...

---

J'ai strictement rien compris à ce que tu me dis là.

Citation:

---

t'es sûr de ne pas avoir un htmlentities() ou htmlspecialchars() à l'affichage également ? Quand tu dis dans la base il y a "<w>", comment le sais tu ? comment vérifies tu ?

---

Bon alors j'ai bien tout revérifier pour ne pas faire une réponse bidon, mais je l'avais déjà fait: la seule chose que je fais à l'affichage c'est un stripslashes().
Donc comme j'ai dit quand j'ai &lt;w&gt; dans le champ hidden, je récupère <w> dans la base et idem à l'affichage (soit rien sur l'écran mais <w> dans le code source.
Par contre si un htmlentities() est appliqué sur le &lt;w&gt; alors j'obtiens &amp;lt;w&amp;gt; dans le champ hidden (le & étant à son tour converti) et cette fois j'obtiens &lt;w&gt; dans la base et donc s'affiche <w> à l'écran lors de l'affichage.
Et là je viens juste de revérifier je ne fais absolument rien entre le moment ou c'est écrit &amp;lt;w&amp;gt; dans le champ hidden et celui où l'on retrouve &lt;w&gt; dans la base (si ce n'est un mysql_real_escape_string suivi d'un Ucfirst() qui a priori n'ont rien à voir là dedans).

Vous comprenez ?

Oui, il se trouve que PHP a tendance à lancer des urldecode() sur les variables envoyées par l'utilisateur. Sans qu'on le lui demande...
Bref, il est conseillé par à peu près tout le monde de ne pas enregistrer des entités HTML dans la base de données (à part si ces entités font patie du texte à enregistrer, bien sûr) car ce n'est pas ce à quoi sert une BDD.

Une BDD sert à enregistrer des informations brutes, non traitées.

[Edit] Kioob et moi ne sommes pas d'accord sur ce point mais je le dis tout de même : utilise htmlentities() de préférence à htmlspecialchars().

+1 Yogui (sauf pour htmlentities, évidement :D)

Citation:

---

Une BDD sert à enregistrer des informations brutes, non traitées.

---

Bon bah si je rencontre le problème un jour, je me dirais "flute j'aurais dû écouter les vieux".

Citation:

---

Oui, il se trouve que PHP a tendance à lancer des urldecode() sur les variables envoyées par l'utilisateur

---

Ah voilà une explication !
Mais alors est-ce à dire que si mon hébergement change de version php, alors ça ne fonctionnera plus pareil ?

Tu ne veux vraiment pas faire comme tout le monde dès à présent ? Il me semble que cela résoudrait ton problème illico.
Tu t'entêtes alors que tu sais que tu n'as pas raison :/

Mais j'ai pas de problème, où tu as vu un problème Yogui ? Mon script fonctionne bien. Je veux juste comprendre ce point. Cela étant il serait peut être simplifié en le faisant à votre manière c'est vrai. Mais plus long à l'exécution coté client aussi.

Ce que je me demande c'est ci cette méthode ne risque pas de créer un problème par la suite. Auquel cas effectivement je changerai le script.Pourquoi pas dès maintenant mais bon...

Ou alors prouvez-moi que je ne fais aucune économie substancielle de temps à l'affichage en m'y prenant de cette manière ;)

Parce que si j'affiche 10 messages, je dois tous les filtrer pour transformer les <br> et le BBcode, ça coûte forcément beaucoup de ressources, je pense. Alors que la théorie, si un jour dans une prochaine vie tu imprimes tout ton forum sur des PDF podcastés, ça c'est pas rationnel pour moi.

8O

Donc, ton seul argument, ce sont les performances alors que :
- html_specialchars et html_entities ont un inpact ridicule sur les performances
- tu ne gères pas les caches HTTP, alors que pour l'utilisateur final, c'est peut être la seule chose qui lui offre un gain visible.
- si je ne m'abuse ton système contre le vol de session oblige PHP à se connecter à la base de données à chaque page, déjà ça tue les perfs... et en plus tu fais un UPDATE, donc modification de la table, ce qui implique reconstruction de l'index (s'il y a) et purge du cache MySQL pour cette table... Donc après pourrir volontairement le code, pour gagner moins d'un dixième de milliseconde à l'affichage de la page, je trouve ça complètement déplacé.

Bon par contre c'est quand même louche, ou alors c'est encore le coup du urlencode() :

- Je convertiepar htmlentities().
- Je transforme le BBcode maison :

Code:

---

1 2 3 4

$contenu=str_replace("[a=&quot;http://", "<a href=\"http://", "$contenu"); $contenu=str_replace("[a=&quot;", "<a href=\"http://", "$contenu"); $contenu=str_replace("&quot;]", "\"target=\"_blank\"\">", "$contenu");

---

- Je fais de nouveau $contenu=htmlentities($contenu).

Ce qui comme je le disais est absurde, puisque cela devrait me donner une url codée dans la base et donc s'affichant sur la page au lieu d'être cliquable.
Or, dans la base, sans aucune autre intervention, je récupère <a href="..."></a>, c'est à dire quelque chose d'absolument pas converti, comme si le dernier htmlentities ne faisait rien (alors qu'il est utile pour insérer le contenu dans le champs hidden, sans quoi celui ci foire, notamment à cause des quotes dans les liens. Quand je dis ça foire, ça veut dire que ça s'affiche aussi sur la page en plus d'être dans le hidden).

:aie: :? :mouarf: :lol: 8O

Citation:

---

Envoyé par Kioob

8O

Donc, ton seul argument, ce sont les performances alors que :
- html_specialchars et html_entities ont un inpact ridicule sur les performances
- tu ne gères pas les caches HTTP, alors que pour l'utilisateur final, c'est peut être la seule chose qui lui offre un gain visible.
- si je ne m'abuse ton système contre le vol de session oblige PHP à se connecter à la base de données à chaque page, déjà ça tue les perfs... et en plus tu fais un UPDATE, donc modification de la table, ce qui implique reconstruction de l'index (s'il y a) et purge du cache MySQL pour cette table... Donc après pourrir volontairement le code, pour gagner moins d'un dixième de milliseconde à l'affichage de la page, je trouve ça complètement déplacé.

---

Bon admettons... Mais il n'y a pas que le htmlentities, il y a aussi les str_replace pour le BBCode...
J'attend vos réponses pour mon post avant et je vois ce que je fais en fonction.

(Tu l'as approfondi ou quoi "mon" système "anti vol de session" ?)

Du reste je suis obligé de faire un htmlentities avant l'insertion dans la base, non par plaisir mais parce que sinon le contenu censé s'afficher dans le champ hidden s'affiche aussi sur la page...

**edit**
Et puis quand j'y pense, vous me dites après l'affichage, mais même ici ça se fait avant. sinon comment moi je pourrais lire dans la prévisualisation, ce qui vous lisez tel quel ci dessous :
<a href="http://www.lesitequifume.com">le site qui fume</a> ?

Pour le BBCode, c'est poil différent quand même. Il s'agit là d'un traitement assez lourd (surtout s'il est mal fait). Pour ça, j'utilise 2 champs dans ma base de données :
- un premier champ de type "TEXT", qui contient le texte brut, sans modification.
- un deuxième champ de type "BLOB", qui contient, sous forme compressée, la version parsée du texte.

Un des avantages aussi c'est qu'en cas de modification/correction du moteur du forum, un "UPDATE matable set champblob = NULL;" suffit. Ce champ BLOB ne sert que de cache, et à ce titre il peut être supprimé et reconstruit à tout moment.


<HS>
Pour ton système "anti vol", j'ai lu quelques messages, et effectivement certains aspects me plaisent. Je me suis d'ailleurs inspiré du principe pour modifié ma classe de gestion des sessions, histoire de faire abstraction du session_regenerate_id().
</HS>

Citation:

---

Du reste je suis obligé de faire un htmlentities avant l'insertion dans la base, non par plaisir mais parce que sinon le contenu censé s'afficher dans le champ hidden s'affiche aussi sur la page...
[...]

---

gna ??? :aie: Perso je ne vois aucun rapport... de quoi parles tu ?
Le htmlspecialchars() chez moi il n'est fait qu'une seule fois, et c'est au moment de l'affichage, quand je fais un "echo". Et c'est tout.

Citation:

---

Pour le BBCode, c'est poil différent quand même. Il s'agit là d'un traitement assez lourd (surtout s'il est mal fait).

---

T'insinues un truc là ?

Citation:

---

un deuxième champ de type "BLOB", qui contient, sous forme compressée, la version parsée du texte.

---

Je sais pas ce que c'est ni comment ça s'utilise. Je viens de chercher sur google, j'ai pas trouver grand chose (rien même, mais j'ai pas fouillé à mort).
**edit** à l'instant où j'écris ça je viens de me rendre compte que j'ai cherché un truc html du genre <input type="blob">...

Citation:

---

<HS>
Pour ton système "anti vol", j'ai lu quelques messages, et effectivement certains aspects me plaisent. Je me suis d'ailleurs inspiré du principe pour modifié ma classe de gestion des sessions, histoire de faire abstraction du session_regenerate_id().
</HS>

---

Comme quoi même un jeune blaireau qui n'en veut peut intéresser les vétérans.

Citation:

---

Le htmlspecialchars() chez moi il n'est fait qu'une seule fois, et c'est au moment de l'affichage, quand je fais un "echo". Et c'est tout.

---

Je dis que sur le présent forum, et présent champ de formulaire où j'écris le présent message, si j'écris une url pointant vers google que je clique prévisualiser, je vais voir l'url telle quelle et non transcrite. Donc les symboles ont été encodés par htmlspecialchars, sans quoi ça donnerait un lien. Et pourtant la prévisualisation se fait sans que le message soit envoyé dans la base. Donc faut pas être parano non plus mon système est pas catastrophique, par contre je me demande si un changement de version php chez ovh ne m'obligera pas à le revoir du fait d'un éventuel disfonctionnement du urlencode() mentionné par Yogui.

Et en plus je vous ai pas dit que je fais pas de requête sql avec jointure naturelle, j'insère des champs d'une table X à l'intérieur d'une table Y pour tout afficher d'un coup....
( :sm: ? )

Citation:

---

Envoyé par psychoBob

T'insinues un truc là ?

---

Pas par rapport à toi si ça peut te rassurer ;) Mais plutot vis à vis de trucs hideux comme phpBB et ses divers modules, qui font passer le code dans un nombre incroyable de regexp... M'enfin, ce n'est pas le sujet.

Citation:

---

Je sais pas ce que c'est ni comment ça s'utilise. Je viens de chercher sur google, j'ai pas trouver grand chose (rien même, mais j'ai pas fouillé à mort).
**edit** à l'instant où j'écris ça je viens de me rendre compte que j'ai cherché un truc html du genre <input type="blob">...

---

Il n'y a rien de bien interessant : en gros un champ BLOB sous MySQL est un champ "binaire" de taille illimité... un gros foure-tout quoi, parfaitement adapté pour mettre des trucs qui ne sont jamais utilisés dans les clauses SQL.

Citation:

---

Comme quoi même un jeune blaireau qui n'en veut peut intéresser les vétérans.

---

lol :)

Citation:

---

Je dis que sur le présent forum, et présent champ de formulaire où j'écris le présent message, si j'écris une url pointant vers google que je clique prévisualiser, je vais voir l'url telle quelle et non transcrite. Donc les symboles ont été encodés par htmlspecialchars, sans quoi ça donnerait un lien. Et pourtant la prévisualisation se fait sans que le message soit envoyé dans la base.

---

euh... je ne suis toujours pas.... un formulaire de prévisualisation, bah... ça passe pas du tout par la base de données, donc forcément le htmlspecialchars() ne sera pas fait avant l'insertion en base... :s

Citation:

---

Donc faut pas être parano non plus mon système est pas catastrophique, par contre je me demande si un changement de version php chez ovh ne m'obligera pas à le revoir du fait d'un éventuel disfonctionnement du urlencode() mentionné par Yogui.

---

Pas catastrophique, mais source d'ennuis à moyen terme. Donc quand tu viens sur un forum en disant que tu rencontre déjà des problèmes avec ce genre, normal qu'on te prévienne dès maintenant. Maintenant tu es grand, tu fais comme tu veux, mais viens pas te plaindre que tu t'en sors pas avec tous tes mic/mac de conversions et échapements en tous genre. :)

Bon de toute façon je vois pas comment faire.

Admettons que je ne passe par htmlentities() avant l'insertion dans la base.
Premier problème : mon contenu ne veut pas rentrer dans le champ hidden, comme je l'ai dit il s'affiche.
Déjà c'est réglé je suis obligé d'utiliser htmlentities().

Admettons que je trouve une solution pour ça.
Je fais quand même on str_replace avant l'insertion dans la base pour ne pas le faire à l'affichage. Au final dans la base je me retrouve simplement avec des <br> des <i> des <b> et des <a href> qui sont les balises que j'autorise. Elles ne sont pas converties donc c'est propres.

Maintenant je dois faire htmlspecialchars à l'affichage pour éviter les bonnes blagues des membres et autres codes douteux.

Bon et maintenant, ça va me les convertir mes balises susmentionnées. Par conséquent je suis bon pour un nouveau coup de str_replace() pour que toutes ces balises fassent leur effet sans quoi elles vont s'afficher sur l'écran du visiteur, puisqu'ayant été converties dans leur équivalent texte.

Ou alors vous allez me dire que l'on peut exclure dans le htmlspecialchars() certaines balises ?

euh... quand on te dit de ne pas faire d'htmlspecialchars() sur tes données avant de les inserrer en base, ça veut dire que tu ne dois pas les modifier...

tu peux parfaitement faire ceci :

Code:

---

1 2 3

$a = '<a href="">'; echo htmlspecialchars( $a ); $requete = " insert into bidule values( '" . mysql_real_escape_string( $a ) ." ')" ;

---

Mais pas ça :

Code:

---

1 2 3

$a = '<a href="">'; $a = htmlspecialchars( $a ); $requete = " insert into bidule values( '" . mysql_real_escape_string( $a ) ." ')" ;

---

L'essentiel étant que ne modifies pas les données.

Donc echo htmlspecialchars($a), ne modifie pas $a mais l'affiche modifié. C'est ça ? Bon admettons.

Mais ça ne règle pas l'autre problème, concernant le BBCode.
Comme j'ai dit si je le transforme par str_replace en bon code html avant l'insertion dans la base, mais sans faire aucun htmlspecialchars à ce moment là, alors je dois faire mon htmlspecialchars lors de l'affichage, comme vous le dites d'ailleurs.

Bon, mais alors mon code html issue du BBcode est de nouveau convertie, et je n'ai plus qu'à refaire mon str_replace, ce qui coute des ressources.
La seule solution que je vois c'est d'exclure de htmlspecialchars certaines balises.

Une question pratique tiens, les forums phpBB convertissent le BBcode avant l'insertion ou lors de l'affichage ?

Citation:

---

Envoyé par psychoBob

Donc echo htmlspecialchars($a), ne modifie pas $a mais l'affiche modifié. C'est ça ? Bon admettons.

---

Exactement.

Citation:

---

Mais ça ne règle pas l'autre problème, concernant le BBCode.
Comme j'ai dit si je le transforme par str_replace en bon code html avant l'insertion dans la base, mais sans faire aucun htmlspecialchars à ce moment là, alors je dois faire mon htmlspecialchars lors de l'affichage, comme vous le dites d'ailleurs.

Bon, mais alors mon code html issue du BBcode est de nouveau convertie, et je n'ai plus qu'à refaire mon str_replace, ce qui coute des ressources.
La seule solution que je vois c'est d'exclure de htmlspecialchars certaines balises.

---

De toutes façons si tu affiches une page prévisualisation, c'est pour que l'utilisateur puisse modifier non ? Du coup, puisque l'utilisateur a de grandes chances d'avoir modifié sa saisie, tu es obligé de refaire ton traitement BBcode.

Citation:

---

Une question pratique tiens, les forums phpBB convertissent le BBcode avant l'insertion ou lors de l'affichage ?

---

Aucune idée, mais dans tous les cas ce n'est pas forcément un bon exemple non plus... phpBB est loin d'être réputé pour ses performances, ni pour la propreté de son code, ni pour sa politique de sécurité d'ailleurs... en fait, phpBB ne plait qu'aux utilisateurs (et c'est déjà bien).
Sans rentrer dans le troll, c'est un peu comme les vieux Windows : c'est mal fichu, pas pratique, lent, plein de faille. Mais c'est l'OS le plus répendu...

Note : il s'agit d'un exemple, d'une illustration, pas la peine d'entrer dans une polémique là dessus...

Citation:

---

Citation:
Mais ça ne règle pas l'autre problème, concernant le BBCode.
Comme j'ai dit si je le transforme par str_replace en bon code html avant l'insertion dans la base, mais sans faire aucun htmlspecialchars à ce moment là, alors je dois faire mon htmlspecialchars lors de l'affichage, comme vous le dites d'ailleurs.

Bon, mais alors mon code html issue du BBcode est de nouveau convertie, et je n'ai plus qu'à refaire mon str_replace, ce qui coute des ressources.
La seule solution que je vois c'est d'exclure de htmlspecialchars certaines balises.

De toutes façons si tu affiches une page prévisualisation, c'est pour que l'utilisateur puisse modifier non ? Du coup, puisque l'utilisateur a de grandes chances d'avoir modifié sa saisie, tu es obligé de refaire ton traitement BBcode.

---

Non mais là je parle de l'affichage définitif du message, sur les pages dédiées à cet effet, après validation et tout. Donc le traitement du BBcode je le fais avant l'insertion dans la base. Et après, à l'affichage je passe le htmlspeciachars. Qui me casse toutes mes balises html issues de la conversion du BBcode. Donc je dois alors retraiter tout mon BBcode. Ou alors on peut exclure de htmlspecialchars certaines balises html, ce dont je doute du reste.
C'est plus clair ?

ah ok j'y suis. Bah pour ma part le traitement qui se charge des BBCode est un traitement de "transformation en HTML", et à ce titre il produit du HTML, et on ne fait pas de htmlspecialchars() pour afficher du HTML...

Non mais là ça va pas, je dois bien m'en servir de htmlspecialchars sinon on va m'afficher tout et n'importe quoi sur mon forum, scripts javascripts et compagnie.
Bon donc je dois le filtrer à un moment ou un autre le message.
Avant l'insertion vous voulez pas.
Après l'insertion, mais alors ça me convertie mes balises html issues du bbCode convertie par str_replace() avant l'insertion dans la base.
Donc j'ai plus qu'à repasser les str_replace() sur les balises html converties en texte pour les reconvertirs en <>.
Or les str_replaces c'est avant l'insertion sans quoi on était à peu près d'accord, dans ma compréhension des choses, pour dire que ça c'est quand même trop long à faire lors de l'affichage, contrairement à htmlspecialchars qui est encore tolérable en terme de temps d'affichage.

Non : tu as un traitement de "transformation en HTML". Ce traitement est indissociable. Donc soit tu fais htmlspecialchars => bbcode => mysql, soit mysql => htmlspecialchars => bbcode ; mais évidement pas bbcode => mysql => htmlspecialchars...
Sinon ça ne sert à rien le traitement bbcode a les mêmes défauts que le htmlspecialchars, à savoir qu'il dénature les données.

Je précise d'autre part que pour moi c'est au "traitement bbcode" de s'assurer du travail de htmlspecialchars : si un jour tu veux ajouter des smileys avec ce code "; )" tu vas avoir plein de problèmes dans tes messages à cause de caractères "&eacute;" ou "&amp;" par exemple qui vont être changés en smileys...
"bbcode" sert à changer du texte "brut" en HTML, et "htmlspecialchars" aussi... donc forcément, si tu utilises les deux cumulés, tu vas avoir des conflits.
Mais ceci est un autre sujet :D

Mouich

Citation:

---

tu fais htmlspecialchars => bbcode => mysql

---

C'est ce que je fais hein... sauf que je rajoute un htmlspeciachars pour pouvoir faire entrer le contenu dans le texte hidden, mais comme tu l'as dis, je peux peut-être faire un simple echo htmlspecialchars($contenu).

Bon allez zou ça fonctionne comme ça, on verra quand ça buggera. En tout cas j'ai appris des choses, merci ;)

alors une dernière question, histoire de t'embèter : pourquoi diable mets tu le résultat de ton traitement d'affichage, qui ne sert donc qu'à l'affichage, dans un champ hidden ? :D

En fait ça se passe comme ça :

1. Le gars clique "poster un commentaire"
2. Il arrive sur une page avec un champ texte pour le titre et un textarea pour le contenu.
3. Il clique prévisualiser.
4. Une nouvelle page s'affiche:
5. en haut son commentaire tel qu'il apparaitra.
6. En dessous un bouton "envoyer".
7. Encore en dessous son message dans le textarea. S'il le modifie, il reclique "prévisualiser", et ainsi de suite, il se réaffiche etc....
8. Dans le code, le titre et le contenu sont dans des champs hidden, dans un form dont fait parti le bouton "envoyer".
9. C'est ce form et ces champs hidden qui contiennent les données qui sont ensuite envoyées à la page d'insertion dans la base.

(Il y a plein de vérifications, sur la taille des données, les grossièretés etc... mais je passe les explications).

Citation:

---

pourquoi diable mets tu le résultat de ton traitement d'affichage, qui ne sert donc qu'à l'affichage, dans un champ hidden ?

---

Donc je le met dans un champ hidden pour l'envoyer à la page finale chargée d'insérer les données dans la base. Car j'ai deux forms sur la même page : un pour prévisualiser et un pour envoyer. Dans prévisualiser il y a les données en clair, prêtes à être modifiées, et dans le form avec le bouton envoyer, les données sont dans les champs hidden.

Je sais pas si c'est clair comme ça mais en fait ça fonctionne très exactement comme n'importe quel forum (sauf qu'il n'y a pas de bouton pour envoyer directement les données, on est obligé de prévisualiser d'abord, mais bon...)

ok, je comprends bien.

Maintenant qu'est ce qu'il se passe si je modifie le contenu du champ HIDDEN (oui oui, on peut), et que j'y met du code HTML... par exemple <h1>Hello</h1>, tu l'insère tel quel en base de données non ? et tu l'affiches tel quel également...

Ah ouais (très) bien vu, merci !

Au début j'y avais pensé et puis j'ai planché sur les str_replace() et du coup j'ai déplacé l'endroit où j'effectue le filtrage...:roll:

Bon j'ai plus qu'à m'y remettre, je vous tiens au courant...:?

Bon voilà, ce coup ci je suis invulnérable, je met au défit n'importe quel hacker de l'école primaire de pirater mon site.

Merci Kioob :hola:


(cela étant maintenant c'est encore plus crade, j'ai deux fois des str_replace(), une fois pour l'affichage de prévisualisation, et une fois avant l'insertion finale dans la table, puisque mes balises sont pulvérisées par le htmlentities qui réceptionne les données du champs hidden. Mais bon, vaille que vaille on y arrive).

En tout cas Kioob mérite une étoile au guide développez, il m'a évité la faille de poissard. Encore merci !

moarf, bah bon courage pour la suite :D