Insertion HTML et underscore dans base de données

[Shonen]

Bonjour à tous.

J'ai créé mon propre module qui permet à mon client d'avoir des champs supplémentaires sur sa page produit, pour ça j'ai créé deux nouvelles tables dans la base de données (pour la lang), et leurs colonnes respectives de type text (pour remplir avec du HTML).

Exemple d'une nouvelle colonne créé dans ma nouvelle classe :

'reglementation' => array('type' => self::TYPE_HTML, 'lang' => true, 'required' => false, 'validate' => 'isCleanHtml')

Ma fonction d'exemple pour l'ajout d'une colonne :

/* reglementation */
$strRegl = 'reglementation_'.$language['id_lang'];
$regl = explode('_', $_POST[$strRegl]);
$reglVal = $regl[0];
$queryRegl = "UPDATE `"._DB_PREFIX_."pscom_product_fields_lang` pfl
LEFT JOIN `" . _DB_PREFIX_ . "pscom_product_fields` pf ON pf.id_product_fields = pfl.id_product_fields
SET reglementation='".addslashes($reglVal)."' WHERE id_product=".$params['id_product']." AND id_lang=".$language['id_lang'];
Db::getInstance()->Execute($queryRegl);

Jusqu'ici tout fonctionne, lors de l'édition du champ reglementation en back-office, le code HTML est bien inclut en base de données.

SAUF

Si un underscore vient s'incruster. Là tout s'arrête juste avant celui-ci. Exemple de contenu dans la base que je peux avoir :

<div>
  <p>Voici un exemple de contenu HTML inscrit en base, et un lien : <a href="https://monsuperlien.ndd" target="

La détection du _ pour _blank n'est pas inscrite en base de donnée, ce qui génère des bug en front-office puisque la ligne se termine par une " ici.

J'ai vraiment tout essayé

• modifier l'interclassement de ma BDD pour passer en utf8mb4_unicode_ci
• Enlever le addslashes (l'update ne fonctionne alors même plus)
• Utiliser d'autres fonctions comme htmlspecialchars (mais je souhaite conserver le code HTML)
• Utiliser getInstance()>update() (impossible car j'ai un LEFT JOIN obligatoire dans ma query)

Si vous avez des idées je suis preneur !

[doekia]

Désolé, je vais être brutal.

Avant toute chose (en dehors de votre problème) votre code est une porte ouverte a tous les hackers de la terre.
Ne mettez pas ce code en ligne ou vous allez "suicider" les utilisateurs de celui-ci.

Ici addslashes doit devenir pSQL(xx,true) si vous êtes en HTML sur ce champ. Les autres champs doivent être casté en int!

 

Concernant votre problème, il suffit d'utiliser à l'origine un séparateur inexploitable dans un source, et non pas _ comme ici. Préférer un code ASCII invisible (< 0x20)

[Shonen]

Pas de souci je suis preneur de tous conseils !

En effet depuis hier je me suis rabattu sur l'utilisation de pSQL après avoir regardé le code source de la fonction update() de la classe Db de Prestashop.

$queryRegl = "UPDATE `"._DB_PREFIX_."pscom_product_fields_lang` pfl
LEFT JOIN `" . _DB_PREFIX_ . "pscom_product_fields` pf ON pf.id_product_fields = pfl.id_product_fields
SET `reglementation`='".pSQL($reglVal, true)."' WHERE id_product=".$params['id_product']." AND id_lang=".$language['id_lang'];

Par contre pour l'utilisation du underscore, il s'agit d'un bloc wysiwyg, donc c'est l'utilisation native.

Par exemple backOffice :

Front-Office (et donc base de données) :

 

Tout ce qui est _ et après _ n'est pas inscrit en BDD.

Pourtant, voici le retour AJAX de la console :

En base de données, ça s'arrête à 

Quote

gratuitement sur <a href="https://google.fr" target="

Et puis si le client souhaite mettre des _ dans son contenu, c'est aussi impossible.

 

 

Edited January 19, 2023 by Shonen (see edit history)

[Shonen]

Ok, j'ai honte, mais il s'agit de ma ligne 

$regl = explode('_', $_POST[$strRegl]);

Je ne sais même plus pourquoi j'en avais besoin, mais elle est totalement inutile.

Sujet clos ! Merci pour la réponse tout de même @doekia

[doekia]

id_product=".(int)$params['id_product']." AND id_lang=".(int)$language['id_lang'];