Discussion :

[psychoBob]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

$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.

[psychoBob]

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 ?

[Yogui]

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.

[psychoBob]

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.

[Kioob]

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

[psychoBob]

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.

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 ?

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>...

[Kioob]

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...

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...

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 ?

[psychoBob]

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

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

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.

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.

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à.

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 ?

[Yogui]

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().

[Kioob]

+1 Yogui (sauf pour htmlentities, évidement )

[psychoBob]

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".

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 ?

[Yogui]

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 :/

[psychoBob]

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.

[Kioob]

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é.

[psychoBob]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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).

[psychoBob]

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" ?)

[psychoBob]

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> ?

[Kioob]

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>

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 ??? 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.

[psychoBob]

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à ?

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">...

<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.

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....
( ? )

[Kioob]

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.

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.

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

lol

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

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.