[SQL] problème nl2br() et htmlentities() pour validation de form..

Bonjour,

Je m'embrouille un peu dans mon système de commentaire, donc je viens mander votre aide.

J'explique le fonctionnement du/des formulaires en quelques mots, avant de décrire le problème :
1) Il y a un textarea (et d'autres champs mais on simplifie).
2) Le visiteur clique "prévisualiser".
3) La page se recharge avec :
-le texte tel qu'il apparaitra et en dessous un bouton valider (le texte du commentaire est dans un input hidden).
- le texte dans un nouveau formulaire qui permet de modifier le commentaire.
4) Arrivé là, le visiteur valide son commentaire, ou le modifie puis le prévisualise de nouveau etc...

L'affichage fonctionne très bien.


Maintenant ça devient embêtant :
Quand le visiteur valide clique sur prévisualiser, je filtre le tout avec htmlentities() avant de l'afficher, comme expliqué au dessus.

Ca ça fonctionne, c'est pour la sécurité.

Ensuite je place un stripslashes() sur les variables juste avant de les afficher, que ce soit dans l'espace prévisualisation ou dans le formulaire permettant de modifier le message (cela pour éviter les l\è, par exemple).

Cela ça fonctionne aussi.

Ensuite pour permettre le retour à la ligne, j'utilise nl2br()
Cela fonctionne mal, car le htmlentites() désactive le nl2br, ce qui fait la chose suivante:

Le visiteur remplie le formulaire en sautant des lignes.
il prévisualise.
Son message s'affiche correctement dans l'espace de prévisualisation, mais dans le formulaire de modification, les </br> apparaissent. Cela n'est pas encore trop gênant.
Par contre si le visiteur prévisualise de nouveau son message, alors les </br> apparaissent cette fois dans l'espace de prévisualisation, et deux fois dans le formulaire de modification;



Question évidente : comment conserver le saut de ligne, sans qu'il n'apparaissent sous forme de balise du coté du visiteur, dans l'espace de prévisualisation (qui est une simple DIV mise en forme en CSS) et dans le champ de formulaire permettant la modification?


Merci d'avance[/list]

D'un coup d'un seul, j'ai peut être une réponse:

Je crois que l'on peut exclure une ou plusieurs balises de htmlentites().

Ai-je raison? ai-je tort? hum... seul l'avenir nous le dira.

Il faut bien séparer prévisualisation et remplissage du <form>.
Pour la prévisualisation tu as besoin de stripslashes( ), htmlspecialchars( ) et nl2br( )
Pour le remplissage du <form> tu as besoin de stripslashes( ), htmlspecialchars( )
Pour ton pb de nl2br( ), il suffit de l'appliquer au moment de la prévisualisation après le htmlspecialchars( ).

Citation:

---

Je crois que l'on peut exclure une ou plusieurs balises de htmlentites().
Ai-je raison? ai-je tort?

---

Non. Oui ;)

(note : tu as besoin de stripslashes( ) ssi les magic-quotes sont activées)

Merci Seb pour ta réponse,

Avant de voir pour htmlspecialchars, je préfère essayer de conserver htmlentities(), je crois que c'est mieux pour la sécurité.

Donc à défaut d'exclure le </br> d'htmlentities(), je dois pouvoir détecter dans la chaine de caractère ce même </br> afin de le reconvertir en balise html, qui ne s'affiche donc pas.

Ai-je raison, ai-je tort ?

Pour le nl2br(), tu me dis de ne pas l'utiliser dans le formulaire de modification mais seulement dans l'espace de prévisualisation.
Bon, mais est-ce que les saut de ligne vont être automatiquement conservés? (je m'en vais tester tout cela tout de suite).

En fait lorsque j'affiche le message du formulaire dans l'espace de prévisualisation, j'applique la fonction nl2br().

Puis je reprend la même variable pour l'afficher à l'intérieur du formulaire de modification qui se trouve juste en dessous.

Donc la solution me semble bien être de filtrer/convertir cette balise.


Est-ce que c'est bon dans l'idée? Si oui c'est strreplace() que l'on doit utiliser il me semble ?

Bon alors:
Comme Seb m'a fait remarqué de bien séparer l'espace de prévisualisation et le formulaire de vérification, voilà ce que j'ai fait :

Au lieu d'utiliser la même variable pour afficher le contenu dans ces deux zones, je crée deux variables, une avec nl2br() et l'autre sans.

ça fonctionne.
Question : comment se fait-il comme le formulaire reprenne les sauts de lignes comme cela, par magie? J'ai vérifié le code de la page rien ne s'affiche.

Nouveau problème : comme j'insère tout dans la base htmlentities, à l'affichage définitif les </br> sont désactivés et s'affichent.

la solution est donc de les convertir avec strreplace, n'est-ce point-il ?

Donc tout fonctionne mais j'ai quand même une dernière question.

Voilà, j'ai commis la chose suivante et ne sais si elle est très utile :

Quand un visiteur clique sur "prévisualiser", dès la page suivante je filtre le contenu du formulaire avec htmlentities() (pour la sécurité).

Mais ensuite j'ai besoin de stripslashes() pour un affichage correct dans les champs prévisualisation et modification du commentaire.

Donc je crée une nouvelle variable qui reprend la première (filtrée avec htmlentitites) et lui ajoute stripslashes.
Puis j'affiche la variable stripslashées, tandis que l'autre non stripslaschées est passée dans le formulaire hidden.



Est-ce très utile d'avoir ces deux variables (pour la sécurité j'entend)?

Citation:

---

Envoyé par psychoBob

Question : comment se fait-il comme le formulaire reprenne les sauts de lignes comme cela, par magie?

---

Dans un <textarea> le retour à la ligne est codé \r\n et non <br>.
Dans une page HTML fais :

Code:

---

1 2 3

<textarea>Ligne 1 Ligne 2 Ligne 3</textarea>

---

Chaque ligne apparaîtra... à la ligne => pas besoin de <br>

Citation:

---

Nouveau problème : comme j'insère tout dans la base htmlentities, à l'affichage définitif les </br> sont désactivés et s'affichent.

---

Tu insères du texte htmlentifié dans la BdD ?
Il ne faut jamais faire cela, entre autres pour éviter les problèmes que tu rencontres.

1. L'utilisateur saisi du texte
2. Tu l'insères brut en BdD
3. À l'affichage htmlspecialchars( ) puis nl2br( )

Citation:

---

Quand un visiteur clique sur "prévisualiser", dès la page suivante je filtre le contenu du formulaire avec htmlentities() (pour la sécurité).

Mais ensuite j'ai besoin de stripslashes() pour un affichage correct dans les champs prévisualisation et modification du commentaire.

---

Je ferais le stripslashes( ) plutôt avant mais bon.

Citation:

---

Donc je crée une nouvelle variable qui reprend la première (filtrée avec htmlentitites) et lui ajoute stripslashes.
Puis j'affiche la variable stripslashées, tandis que l'autre non stripslaschées est passée dans le formulaire hidden.

---

Euh non, si tu envoies une valeur slashée en HIDDEN elle sera à nouveau slashée autant de fois qu'elle sera resoumise, et au final tu vas te retrouver avec une ribambelle de \ de trop ;)

Citation:

---

Est-ce très utile d'avoir ces deux variables (pour la sécurité j'entend)?

---

J'avoue que là je suis perdu :?

Citation:

---

psychoBob a écrit:
Question : comment se fait-il comme le formulaire reprenne les sauts de lignes comme cela, par magie?

Dans un <textarea> le retour à la ligne est codé \r\n et non <br>.
Dans une page HTML fais :

Code:
<textarea>Ligne 1
Ligne 2
Ligne 3</textarea>


Chaque ligne apparaîtra... à la ligne => pas besoin de <br>

---

D'accord mais ce qui m'étonne c'est que les \r\n sont invisibles dans le code, donc comment-est ce que cela fonctionne ?

Citation:

---

Citation:
Nouveau problème : comme j'insère tout dans la base htmlentities, à l'affichage définitif les </br> sont désactivés et s'affichent.

Tu insères du texte htmlentifié dans la BdD ?
Il ne faut jamais faire cela, entre autres pour éviter les problèmes que tu rencontres.

1. L'utilisateur saisi du texte
2. Tu l'insères brut en BdD
3. À l'affichage htmlspecialchars( ) puis nl2br( )

---

Bah non, si le visiteur me balance une injection sql ou un script de derrière les fagots, je dois le filtrer avant l'insertion dans la base !

Citation:

---

D'accord mais ce qui m'étonne c'est que les \r\n sont invisibles dans le code, donc comment-est ce que cela fonctionne ?

---

?! Ben dans l'exemple que je t'ai donné on voit bien les \r\n représenté à l'écran par des retours à la ligne.

Citation:

---

Bah non, si le visiteur me balance une injection sql ou un script de derrière les fagots, je dois le filtrer avant l'insertion dans la base !

---

L'injection SQL sera évitée avec mysql_real_escape_string( ), rien d'autre.

Citation:

---

Ben dans l'exemple que je t'ai donné on voit bien les \r\n représenté à l'écran par des retours à la ligne.

---

Oui mais pas quand on visualise le code source.
Donc comment ces saut de lignes sont-ils gérés ?

Citation:

---

L'injection SQL sera évitée avec mysql_real_escape_string( ), rien d'autre.

---

Je ne connais pas cette fonction.
Pourquoi est-ce un problème de ne pas gérer que des données brutes dans la base ? Est-ce uniquement pour une raison d'affichage ou il y a t'il d'autres raisons ?

Citation:

---

Envoyé par psychoBob

Citation:

---

Ben dans l'exemple que je t'ai donné on voit bien les \r\n représenté à l'écran par des retours à la ligne.

---

Oui mais pas quand on visualise le code source.

---

Si si.

Citation:

---

Pourquoi est-ce un problème de ne pas gérer que des données brutes dans la base ? Est-ce uniquement pour une raison d'affichage ou il y a t'il d'autres raisons ?

---

Par exemple pour des raisons de portabilité. Si tu codes tes données en HTML tu devras certainement un jour les décoder pour les exporter au format texte, PDF, etc.

Citation:

---

psychoBob a écrit:
Citation:
Ben dans l'exemple que je t'ai donné on voit bien les \r\n représenté à l'écran par des retours à la ligne.

Oui mais pas quand on visualise le code source.

Si si.

---

Ah oui je viens de vérifier ça affiche des </br>. C'est moins surnaturel comme ça.

Citation:

---

Citation:
Pourquoi est-ce un problème de ne pas gérer que des données brutes dans la base ? Est-ce uniquement pour une raison d'affichage ou il y a t'il d'autres raisons ?

Par exemple pour des raisons de portabilité. Si tu codes tes données en HTML tu devras certainement un jour les décoder pour les exporter au format texte, PDF, etc.

---

Ok c'est une raison, j'essaierai d'y penser à l'occasion.


merci Seb :D