Remplacement de safehtml par le plug htmlpurifier ou autre #3926

Closed
opened 6 years ago by Franck · 41 comments
Franck commented 6 years ago

Bonjour :-)
Je fais un ticket, sinon, il y aura oubli, la lib safehtml n'a plus de mise à jour dispo et n'est même plus trouvable, si je suis le lien qu'il y a https://zone.spip.org/trac/spip-zone/browser/core/plugins/safehtml/lib/safehtml/classes/safehtml.php#L14
Sur la zone, il y a un plug qui semble pouvoir résoudre le problème https://zone.spip.org/trac/spip-zone/browser/plugins/htmlpurifier après, je ne sais pas si il y a une autre lib qui serait mieux, mais en tout cas, il y a déjà une solution.
Je suppose que cela représente trop de boulot pour la 3.2, surtout que maintenant la version alpha est dispo, mais c'est peut-être possible pour la version 3.3 ?
Franck

Bonjour :-) Je fais un ticket, sinon, il y aura oubli, la lib safehtml n'a plus de mise à jour dispo et n'est même plus trouvable, si je suis le lien qu'il y a https://zone.spip.org/trac/spip-zone/browser/_core_/plugins/safehtml/lib/safehtml/classes/safehtml.php#L14 Sur la zone, il y a un plug qui semble pouvoir résoudre le problème https://zone.spip.org/trac/spip-zone/browser/_plugins_/htmlpurifier après, je ne sais pas si il y a une autre lib qui serait mieux, mais en tout cas, il y a déjà une solution. Je suppose que cela représente trop de boulot pour la 3.2, surtout que maintenant la version alpha est dispo, mais c'est peut-être possible pour la version 3.3 ? Franck

Je me permet de rebondir sur ce ticket pour lancer la discussion, expliquer le travail déjà réalisé de mon coté et les problèmes rencontrés :

un constat : on rencontre souvent des contenus HTML devant passer dans safehtml() qui ne respecte pas à la lettre la spécification, quelques exemples :

Ces morceaux de code HTML seront systématiquement normalisé par htmlPurifier ; ce qui est une bonne chose.

Cela pose un problème d'incompatibilité avec le fonctionnement de la fonction echapper_html_suspect() https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/texte_mini.php#L471 :

if (strlen(safehtml($texte)) !== strlen($texte)) {

Tous les contenus modifiés car normalisés se retrouveront donc encodés puis affichés :(

Plusieurs solutions :

  • changer la logique de la fonction echapper_html_suspect() pour faire confiance à safehtml()`htmlPurifier
  • normaliser tout ce qui est susceptible de passer à travers cette fonction pour éviter ces modifications et conserver cette logique
Je me permet de rebondir sur ce ticket pour lancer la discussion, expliquer le travail déjà réalisé de mon coté et les problèmes rencontrés : un constat : on rencontre souvent des contenus HTML devant passer dans safehtml() qui ne respecte pas à la lettre la spécification, quelques exemples : * mélange de guillemet simple et double comme délimiteur de valeur d'attribut dans une même balise * utilisation du caractère & non encodé dans des a href (& vs &), par exemple : https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/presentation_mini.php#L243 Ces morceaux de code HTML seront systématiquement normalisé par htmlPurifier ; ce qui est une bonne chose. Cela pose un problème d'incompatibilité avec le fonctionnement de la fonction echapper_html_suspect() https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/texte_mini.php#L471 : ``` if (strlen(safehtml($texte)) !== strlen($texte)) { ``` Tous les contenus modifiés car normalisés se retrouveront donc encodés puis affichés :( Plusieurs solutions : * changer la logique de la fonction echapper_html_suspect() pour faire confiance à safehtml()`htmlPurifier * normaliser tout ce qui est susceptible de passer à travers cette fonction pour éviter ces modifications et conserver cette logique

Tant que j'y pense, un autre "problème" :

safehtml()`htmlPurifier transforme les entités HTML dans leur correspondance UTF8 (ce que safehtml() actuel ne fait pas), on se retrouve encore dans le cas avec des longeurs de chaines différentes et donc du texte HTML encodé puis affiché.

Tant que j'y pense, un autre "problème" : safehtml()`htmlPurifier transforme les entités HTML dans leur correspondance UTF8 (ce que safehtml() actuel ne fait pas), on se retrouve encore dans le cas avec des longeurs de chaines différentes et donc du texte HTML encodé puis affiché.

Et on a donc une longueur différente dès qu'on a une apostrophe ' transformée en ’
Et c'est ici que ça se passe : https://core.spip.net/projects/spip/repository/entry/spip/ecrire/typographie/fr.php#L27

Et on a donc une longueur différente dès qu'on a une apostrophe ' transformée en ’ Et c'est ici que ça se passe : https://core.spip.net/projects/spip/repository/entry/spip/ecrire/typographie/fr.php#L27

Après avoir passé pas mal de temps à chercher une solution sécurisée ET fonctionnelle, voilà ce à quoi je suis arrivé sans tout casser ou devoir normaliser "100ans d'historique". La version de SPIP utilisé est SPIP 3.2.1 [23954]. En court : j'inverse la logique actuelle et je fais confiance à la sortie de safehtml du plugin Purifier :

j'ai modifié la fonction echapper_html_suspect() de inc/texte_mini.php, la fonction echappe_anti_xss() du plugin textwheel et 2 règles YAML et... c'est tout :

inc/texte_mini.php :

function echapper_html_suspect($texte, $strict=true) {
	if (!$texte
		or strpos($texte, '<') === false or strpos($texte, '=') === false) {
		return $texte;
	}
	// quand c'est du texte qui passe par propre on est plus coulant tant qu'il y a pas d'attribut du type onxxx=
	// car sinon on declenche sur les modeles ou ressources
	if (!$strict and
	  (strpos($texte,'on') === false or !preg_match(",<\w+.*\bon\w+\s*=,UimsS", $texte))
	  ){
		return $texte;
	}

	$safed_texte = safehtml($texte);
	if (strlen($safed_texte) !== strlen($texte)) {
		$texte = $safed_texte;
	}
	return $texte;
}

plugins-dist/textwheel/wheels/spip/echappe-js.php :

function echappe_anti_xss($match) {
	static $safehtml;
	if (!is_array($match) or !strlen($match[0])) {
		return "";
	}
	$texte = &$match[0];
  
	if ( 
    (strpos($texte, ":") !== false and preg_match(",(data|script)\s*:,iS", $texte) ) or 
		(stripos($texte, "on") !== false and preg_match(",\bon\w+\s*=,i", $texte) )
	) {
		if (!isset($safehtml)) {
			$safehtml = charger_fonction('safehtml', 'inc', true);
		}
		$texte = $safehtml($texte);		
	}
	return $texte;
}

plugins-dist/textwheel/wheels/spip/echappe-js.yaml :

-
  if_str: "<script"
  match: "{<script.*?($|</script.)}isS"
  is_wheel: y
  replace:
    -
      type: all
      replace: htmlspecialchars
      is_callback: Y
    -
      type: all
      replace: nl2br
      is_callback: Y
    -
      type: all
      replace: "<code class=\"echappe-js\">$0`"

-
  if_str: "<"
  match: "{<[a-z]+.*?($|>)}UisS"
  is_callback: Y
  replace: echappe_anti_xss

plugins-dist/textwheel/wheels/spip/interdire-scripts.yaml :

securite-js:
  if_str: "<"
  if_match: "/<[a-z]+/iS"
  type: all
  replace: "echappe_js"
  is_callback: Y

Pour le moment, du coté des effets de bord/choses cassées (nos fonctions sont remplis de spip_log() et on affiche le code impacté par safehtml() pour identifier rapidement les régressions) :

  • le changement de statut via le survol des puces (onmouseover inline) n'existe plus car l'attribut onmouseover est supprimé par htmlPurifier (rien de compliqué a fixer à mon sens, mieux cela oblige à développer (très) proprement, jme propose pour le patch si besoin)

Sinon pas de problème, on publie/modifie/supprime nos objets éditoriaux comme d'habitude, leur mise en forme n'a pas bougé, on install/update/supprime nos plugins, stats OK, config OK, etc, etc (cela fait déjà plusieurs jours que nous utilisons ces modifications).

Coté performance, la machine virtuelle est suivi via SNMP/librenms et on ne voit aucune différence d'utilisation CPU (merci le cache SPIP et OPcache) entre avant/après. D'autre part, htmlPurifier n'est pas appelé tout le temps, loin de là, on ne passe que "rarement" les conditions dans echappe_anti_xss().

Coté sécurité :

  • les charges javascript 954b4d3a29/xss_vectors.txt ont toutes été testées sans problème
  • safehtml($_GET[]) a passé les tests des scanners de vulnérabilité web BURP Pro et Acunetix Web Scanner sans problème

Coté publication :
Cela me semble risqué d'attendre une version majeure de SPIP avant de corriger ces problèmes de sécurité ; surtout que la transition peut se faire doucement en 3.2 avec une nouvelle version de textwheel et le remplacement (enfin) de plugin-dist/safehtml par htmlpurifier.

En espérant que ça aide et vous serve de base pour la suite.

g0uZ

Après avoir passé pas mal de temps à chercher une solution sécurisée ET fonctionnelle, voilà ce à quoi je suis arrivé sans tout casser ou devoir normaliser "100ans d'historique". La version de SPIP utilisé est SPIP 3.2.1 [23954]. En court : j'inverse la logique actuelle et je fais confiance à la sortie de safehtml du plugin Purifier : j'ai modifié la fonction echapper_html_suspect() de inc/texte_mini.php, la fonction echappe_anti_xss() du plugin textwheel et 2 règles YAML et... c'est tout : inc/texte_mini.php : ``` function echapper_html_suspect($texte, $strict=true) { if (!$texte or strpos($texte, '<') === false or strpos($texte, '=') === false) { return $texte; } // quand c'est du texte qui passe par propre on est plus coulant tant qu'il y a pas d'attribut du type onxxx= // car sinon on declenche sur les modeles ou ressources if (!$strict and (strpos($texte,'on') === false or !preg_match(",<\w+.*\bon\w+\s*=,UimsS", $texte)) ){ return $texte; } $safed_texte = safehtml($texte); if (strlen($safed_texte) !== strlen($texte)) { $texte = $safed_texte; } return $texte; } ``` plugins-dist/textwheel/wheels/spip/echappe-js.php : ``` function echappe_anti_xss($match) { static $safehtml; if (!is_array($match) or !strlen($match[0])) { return ""; } $texte = &$match[0]; if ( (strpos($texte, ":") !== false and preg_match(",(data|script)\s*:,iS", $texte) ) or (stripos($texte, "on") !== false and preg_match(",\bon\w+\s*=,i", $texte) ) ) { if (!isset($safehtml)) { $safehtml = charger_fonction('safehtml', 'inc', true); } $texte = $safehtml($texte); } return $texte; } ``` plugins-dist/textwheel/wheels/spip/echappe-js.yaml : ``` - if_str: "<script" match: "{<script.*?($|</script.)}isS" is_wheel: y replace: - type: all replace: htmlspecialchars is_callback: Y - type: all replace: nl2br is_callback: Y - type: all replace: "<code class=\"echappe-js\">$0`" - if_str: "<" match: "{<[a-z]+.*?($|>)}UisS" is_callback: Y replace: echappe_anti_xss ``` plugins-dist/textwheel/wheels/spip/interdire-scripts.yaml : ``` securite-js: if_str: "<" if_match: "/<[a-z]+/iS" type: all replace: "echappe_js" is_callback: Y ``` Pour le moment, du coté des effets de bord/choses cassées (nos fonctions sont remplis de spip_log() et on affiche le code impacté par safehtml() pour identifier rapidement les régressions) : * le changement de statut via le survol des puces (onmouseover inline) n'existe plus car l'attribut onmouseover est supprimé par htmlPurifier (rien de compliqué a fixer à mon sens, mieux cela oblige à développer (très) proprement, jme propose pour le patch si besoin) Sinon pas de problème, on publie/modifie/supprime nos objets éditoriaux comme d'habitude, leur mise en forme n'a pas bougé, on install/update/supprime nos plugins, stats OK, config OK, etc, etc (cela fait déjà plusieurs jours que nous utilisons ces modifications). Coté performance, la machine virtuelle est suivi via SNMP/librenms et on ne voit aucune différence d'utilisation CPU (merci le cache SPIP et OPcache) entre avant/après. D'autre part, htmlPurifier n'est pas appelé tout le temps, loin de là, on ne passe que "rarement" les conditions dans echappe_anti_xss(). Coté sécurité : * les charges javascript https://gist.githubusercontent.com/kurobeats/9a613c9ab68914312cbb415134795b45/raw/954b4d3a29cd0fbeb5b841b54126326a6c14a5c1/xss_vectors.txt ont toutes été testées sans problème * safehtml($_GET[]) a passé les tests des scanners de vulnérabilité web BURP Pro et Acunetix Web Scanner sans problème Coté publication : Cela me semble risqué d'attendre une version majeure de SPIP avant de corriger ces problèmes de sécurité ; surtout que la transition peut se faire doucement en 3.2 avec une nouvelle version de textwheel et le remplacement (enfin) de plugin-dist/safehtml par htmlpurifier. En espérant que ça aide et vous serve de base pour la suite. g0uZ

Content de voir que ce patch règle également des problèmes de mise en forme (je n'observe pas ce pb `home), je m'explique :

Dans mon post précédent, dans le contenu du fichier plugins-dist/textwheel/wheels/spip/echappe-js.yaml donné entre les balises

< pre>< code class="yaml">< / code>< / pre>

certains caractères "<" et ">" ont été encodé (mais pas d'autres (!) ) alors qu'à l'origine cette partie de mon post n'en contient aucun.

NB : essayez de mettre en forme avec <pre><code class="html"> la simple ligne de HTML donné dans ce post est ici impossible (les < > sont encodé alors que dans un < code >), une nouvelle fois je n'ai pas ce pb `home

Content de voir que ce patch règle également des problèmes de mise en forme (je n'observe pas ce pb `home), je m'explique : Dans mon post précédent, dans le contenu du fichier plugins-dist/textwheel/wheels/spip/echappe-js.yaml donné entre les balises < pre>< code class="yaml">< / code>< / pre> certains caractères "<" et ">" ont été encodé (mais pas d'autres (!) ) alors qu'à l'origine cette partie de mon post n'en contient aucun. NB : essayez de mettre en forme avec &lt;pre&gt;&lt;code class="html"&gt; la simple ligne de HTML donné dans ce post est ici impossible (les < > sont encodé alors que dans un < code >), une nouvelle fois je n'ai pas ce pb `home
b_b commented 4 years ago
Owner

Merci g0uz, poste plutôt des patch au format diff, cela sera bien plus pratique à lire et à intégrer ;)

Merci g0uz, poste plutôt des patch au format diff, cela sera bien plus pratique à lire et à intégrer ;)
Owner

Salut

Tu peux aussi tester un PR sur git.spip.net/spip ou github

Salut Tu peux aussi tester un PR sur git.spip.net/spip ou github

Bonjour à tous,

ci-joint les patchs permettant de faire la bascule et d'avoir un mode parano fonctionnel, (il faut bien entendu activer le plugin HTMLPurifier) en attendant de l'avoir par défaut dans plugins-dist/safehtml/.

D'avance merci pour vos retours !

Bonjour à tous, ci-joint les patchs permettant de faire la bascule et d'avoir un mode parano fonctionnel, (il faut bien entendu activer le plugin HTMLPurifier) en attendant de l'avoir par défaut dans plugins-dist/safehtml/. D'avance merci pour vos retours !
Owner

Bonjour

Merci pour le patch ::)

Bonjour Merci pour le patch ::)
Owner

On a mise à jour SafeHTML c'est reparti pour 10 ans :)
Version cible mise à 99 plus tard

On a mise à jour SafeHTML c'est reparti pour 10 ans :) **Version cible mise à 99 plus tard**

https://zone.spip.net/trac/spip-zone/browser/spip-zone/plugins/htmlpurifier

La version du trunk est à mon sens bonne pour être testée à partir de SPIP 3.2 (on l'utilise désormais depuis un bon moment sans problème hormis le onmouveover sur les puces de statuts qui est supprimé).

https://zone.spip.net/trac/spip-zone/browser/spip-zone/_plugins_/htmlpurifier La version du trunk est à mon sens bonne pour être testée à partir de SPIP 3.2 (on l'utilise désormais depuis un bon moment sans problème hormis le onmouveover sur les puces de statuts qui est supprimé).
Owner

Depuis https://core.spip.net/projects/spip/repository/revisions/24131 le plugin HTMLPurifier est fonctionel sans nécessiter de patch dans le core ?
on est bon et on peut release tel quel en indiquant que le plugin htmlpurifier est disponible pour tests et se laisser le temps ?

Je pense que si on doit intégrer le plugin ça sera sur la version dev 3.3, pas sur la version stable, et ça va demander de prendre le temps de voir toutes les modifs et les impacts éventuels que tu n'aurais pas vu ou auxquelles tu n'aurais pas pensé.

Sur la fonction de survol des logos le sujet reste ouvert ? On est en effet d'accord que cette écriture est obsolète et devrait être revue de toute façon, mais c'est donc un point à traiter dans le core le cas échéant

Depuis https://core.spip.net/projects/spip/repository/revisions/24131 le plugin HTMLPurifier est fonctionel sans nécessiter de patch dans le core ? on est bon et on peut release tel quel en indiquant que le plugin htmlpurifier est disponible pour tests et se laisser le temps ? Je pense que si on doit intégrer le plugin ça sera sur la version dev 3.3, pas sur la version stable, et ça va demander de prendre le temps de voir toutes les modifs et les impacts éventuels que tu n'aurais pas vu ou auxquelles tu n'aurais pas pensé. Sur la fonction de survol des logos le sujet reste ouvert ? On est en effet d'accord que cette écriture est obsolète et devrait être revue de toute façon, mais c'est donc un point à traiter dans le core le cas échéant

Sorry je n'avais pas vu ce message :

cedric - a écrit :

Depuis https://core.spip.net/projects/spip/repository/revisions/24131 le plugin HTMLPurifier est fonctionel sans nécessiter de patch dans le core ?

Malheureusement si : il reste une surcharge de la fonction propre() via inc/texte.php. Elle est utilisée pour réaliser la protection HTML via echappe_html() AVANT le 1er filtrage de sécurité via echapper_html_suspect(). Un deuxième est réalisé via echappe_retour_modeles($t, $interdire_script) ou $interdire_script est vrai en espacé privé ou si le mode parano actif et faux sinon. (Je n'ai pas su faire autrement, mais il y a peut être une astuce a trouver.)

Je ne sais pas si tu considères que c'est le core mais une surchage des règles YAML de textwheel est également réalisé afin que l'on envoi bien tout qui doit l'être dans les filtres de sécurité.

Donc non pas de modification du core nécessaire pour que le plugin fonctionne. A voir si ces surcharges mériterais une "intégration directe" future.

on est bon et on peut release tel quel en indiquant que le plugin htmlpurifier est disponible pour tests et se laisser le temps ?
A mon avis oui. Pour rappel : le mode parano est actuellement inutilisable avec l'actuel safehtml(). Du coup ça peut être une approche pour l'intégrer/le tester au fil de l'eau : commencé par les gens qui utilisent le mode parano en leur recommandant chaudement/forcant ce plugin.

Ci dessous la liste des plugins que j'utilise sans problème hors textwheel/todo (cf https://core.spip.net/issues/4254) avec htmlPurifier :

Abonnements 3.3.6 - stable
Agenda 3.26.0 - stable
API de vérification 1.8.1 - stable
API Prix 0.1.16 - dev
Article PDF 1.0.10 - stable
Autorité 0.10.20 - stable
Banque&paiement 3.6.7 - stable
Cache Cool 0.5.4 - stable
Challenge Hacking 1.0.0 - stable
Champs Extras 3.11.7 - stable
Chatbox 1.0.5 - stable
Coloration Code 99 - stable
Commandes 1.15.5 - stable
Compositions 3.7.3 - stable
Crayons 1.26.18 - stable
CTF all the day 1.0.0 - stable
Facteur 3.6.2 - stable
Formulaire de contact avancé 0.16.5 - stable
Frimousses 1.5.1 - stable
GIS 4.44.24 - stable
HTML Purifier 5.0.0.1 - test
iCalendar 0.4.5 - test
Import ics 4.4.3 - stable
Imprimer document 0.2.2 - stable
LangOnet 1.4.6 - stable
MailShot 1.27.3 - stable
MailSubscribers 2.11.3 - stable
Markdown 1.0.2 - test
Messagerie 3.1.8 - test
Mini Calendrier 2.4.1 - stable
Mot de passe dès l’inscription 1.0.19 - stable
Newsletters 1.6.0 - stable
Nombres de visiteurs connectés 0.2.3 - stable
NoSPAM 1.5.18 - stable
Notation 2.4.2 - test
Notifications 3.6.8 - stable
Notifications avancées 0.4.2 - test
Pages 1.3.7 - stable
Pre & Code 99 - test
Saisies pour formulaires 3.11.1 - stable
Social tags 1.1.1 - stable
SPIP Bonux 3.4.6 - stable
Tip A Friend 1.6.9 - stable
Todo 2.2.1 - stable
Traduction entre rubriques 3.1.3 - stable
YAML 1.5.4 - stable

Je pense que si on doit intégrer le plugin ça sera sur la version dev 3.3, pas sur la version stable, et ça va demander de prendre le temps de voir toutes les modifs et les impacts éventuels que tu n'aurais pas vu ou auxquelles tu n'aurais pas pensé.

Clairement je pense me faire insulter :-) Je suis prêt ^^ Plus sérieusement il faut absolument tester/restester/reretester. J'ai tenté de faire au mieux mais je ne peux pas revoir tout le code HTML généré par les plugins... Au moindre écart de conformité HTML ca ne passera pas. Le bug https://core.spip.net/issues/4254 en est un bon exemple : avec htmlpurifier l'élément est supprimé ; avec "safehtml() standard" le code invalide est conservé et c'est le navigateur qui va corriger.

Il faut voir les bons cotés: cela force les bonnes pratiques, met SPIP au plus haut niveau du standard (Drupal fait moins bien), aide a identifier des bugs et ce qui passe dans propre() sera obligatoirement valide. C'est aussi a terme moins de problèmes d'injection XSS a traiter pour la team.

Sur la fonction de survol des logos le sujet reste ouvert ? On est en effet d'accord que cette écriture est obsolète et devrait être revue de toute façon, mais c'est donc un point à traiter dans le core le cas échéant

Euh je comprend pas, faut-il intégrer le patch des puces de statut dans ce plugin ? Je pensais plus coder le truc """proprement""" avec un JS dans le <head> directement dans /prive/. A décolérer complètement à mon sens.

Encore merci pour le temps que tu y passes :)

Sorry je n'avais pas vu ce message : cedric - a écrit : > Depuis https://core.spip.net/projects/spip/repository/revisions/24131 le plugin HTMLPurifier est fonctionel sans nécessiter de patch dans le core ? Malheureusement si : il reste une surcharge de la fonction propre() via inc/texte.php. Elle est utilisée pour réaliser la protection HTML via echappe_html() AVANT le 1er filtrage de sécurité via echapper_html_suspect(). Un deuxième est réalisé via echappe_retour_modeles($t, $interdire_script) ou $interdire_script est vrai en espacé privé ou si le mode parano actif et faux sinon. (Je n'ai pas su faire autrement, mais il y a peut être une astuce a trouver.) Je ne sais pas si tu considères que c'est le core mais une surchage des règles YAML de textwheel est également réalisé afin que l'on envoi bien tout qui doit l'être dans les filtres de sécurité. Donc non pas de modification du core nécessaire pour que le plugin fonctionne. A voir si ces surcharges mériterais une "intégration directe" future. > on est bon et on peut release tel quel en indiquant que le plugin htmlpurifier est disponible pour tests et se laisser le temps ? A mon avis oui. Pour rappel : le mode parano est actuellement inutilisable avec l'actuel safehtml(). Du coup ça peut être une approche pour l'intégrer/le tester au fil de l'eau : commencé par les gens qui utilisent le mode parano en leur recommandant chaudement/forcant ce plugin. Ci dessous la liste des plugins que j'utilise sans problème hors textwheel/todo (cf https://core.spip.net/issues/4254) avec htmlPurifier : Abonnements 3.3.6 - stable Agenda 3.26.0 - stable API de vérification 1.8.1 - stable API Prix 0.1.16 - dev Article PDF 1.0.10 - stable Autorité 0.10.20 - stable Banque&paiement 3.6.7 - stable Cache Cool 0.5.4 - stable Challenge Hacking 1.0.0 - stable Champs Extras 3.11.7 - stable Chatbox 1.0.5 - stable Coloration Code 99 - stable Commandes 1.15.5 - stable Compositions 3.7.3 - stable Crayons 1.26.18 - stable CTF all the day 1.0.0 - stable Facteur 3.6.2 - stable Formulaire de contact avancé 0.16.5 - stable Frimousses 1.5.1 - stable GIS 4.44.24 - stable HTML Purifier 5.0.0.1 - test iCalendar 0.4.5 - test Import ics 4.4.3 - stable Imprimer document 0.2.2 - stable LangOnet 1.4.6 - stable MailShot 1.27.3 - stable MailSubscribers 2.11.3 - stable Markdown 1.0.2 - test Messagerie 3.1.8 - test Mini Calendrier 2.4.1 - stable Mot de passe dès l’inscription 1.0.19 - stable Newsletters 1.6.0 - stable Nombres de visiteurs connectés 0.2.3 - stable NoSPAM 1.5.18 - stable Notation 2.4.2 - test Notifications 3.6.8 - stable Notifications avancées 0.4.2 - test Pages 1.3.7 - stable Pre & Code 99 - test Saisies pour formulaires 3.11.1 - stable Social tags 1.1.1 - stable SPIP Bonux 3.4.6 - stable Tip A Friend 1.6.9 - stable Todo 2.2.1 - stable Traduction entre rubriques 3.1.3 - stable YAML 1.5.4 - stable > > Je pense que si on doit intégrer le plugin ça sera sur la version dev 3.3, pas sur la version stable, et ça va demander de prendre le temps de voir toutes les modifs et les impacts éventuels que tu n'aurais pas vu ou auxquelles tu n'aurais pas pensé. > Clairement je pense me faire insulter :-) Je suis prêt ^^ Plus sérieusement il faut absolument tester/restester/reretester. J'ai tenté de faire au mieux mais je ne peux pas revoir tout le code HTML généré par les plugins... Au moindre écart de conformité HTML ca ne passera pas. Le bug https://core.spip.net/issues/4254 en est un bon exemple : avec htmlpurifier l'élément <table> est supprimé ; avec "safehtml() standard" le code invalide est conservé et c'est le navigateur qui va corriger. Il faut voir les bons cotés: cela force les bonnes pratiques, met SPIP au plus haut niveau du standard (Drupal fait moins bien), aide a identifier des bugs et ce qui passe dans propre() sera obligatoirement valide. C'est aussi a terme moins de problèmes d'injection XSS a traiter pour la team. > Sur la fonction de survol des logos le sujet reste ouvert ? On est en effet d'accord que cette écriture est obsolète et devrait être revue de toute façon, mais c'est donc un point à traiter dans le core le cas échéant Euh je comprend pas, faut-il intégrer le patch des puces de statut dans ce plugin ? Je pensais plus coder le truc """proprement""" avec un JS dans le <head> directement dans /prive/. A décolérer complètement à mon sens. Encore merci pour le temps que tu y passes :)
b_b commented 4 years ago
Owner

C'est aussi a terme moins de problèmes d'injection XSS a traiter pour la team

\o/ ho oui ça ferait du bien :)

> C'est aussi a terme moins de problèmes d'injection XSS a traiter pour la team \o/ ho oui ça ferait du bien :)

Le plugin htmlpurifier a été installé pour test sur programmer.spip.net. En mode normal pour l'instant a priori (pas "parano").

  • Tout semble bien se passer.
  • Il n'y a pas de problème pour les actions sur les puces
  • il n'y a pas de problème avec le logo de survol qui fonctionne bien avec les squelettes actuels lorsque la config "Utiliser les logos de survol" est activée
  • Mieux : les problèmes signalés dans #4306 https://core.spip.net/issues/4306 et dûs à safehtml sont tous réglés.

Peut être ces problèmes sont sensés se manifester seulement en mode parano ?

Le plugin htmlpurifier a été installé pour test sur programmer.spip.net. En mode normal pour l'instant a priori (pas "parano"). - Tout semble bien se passer. - Il n'y a pas de problème pour les actions sur les puces - il n'y a pas de problème avec le logo de survol qui fonctionne bien avec les squelettes actuels lorsque la config "Utiliser les logos de survol" est activée - Mieux : les problèmes signalés dans #4306 https://core.spip.net/issues/4306 et dûs à safehtml sont tous réglés. Peut être ces problèmes sont sensés se manifester seulement en mode parano ?

jluc - a écrit :

Le plugin htmlpurifier a été installé pour test sur programmer.spip.net. En mode normal pour l'instant a priori (pas "parano").

  • Tout semble bien se passer.
  • Il n'y a pas de problème pour les actions sur les puces
  • il n'y a pas de problème avec le logo de survol qui fonctionne bien avec les squelettes actuels lorsque la config "Utiliser les logos de survol" est activée
  • Mieux : les problèmes signalés dans #4306 https://core.spip.net/issues/4306 et dûs à safehtml sont tous réglés.

Peut être ces problèmes sont sensés se manifester seulement en mode parano ?

Euh clairement les puces permettant un changement de statut rapide ne sont plus fonctionnelles (attribut onmouse* supprimés) coté privé, y compris sans mode parano (j'ai testé), une fois le plugin activé. Qu'on se comprenne bien : les puces de statut sont la, mais plus rien ne se passe quand on passe la souris dessus.

jluc - a écrit : > Le plugin htmlpurifier a été installé pour test sur programmer.spip.net. En mode normal pour l'instant a priori (pas "parano"). > - Tout semble bien se passer. > - Il n'y a pas de problème pour les actions sur les puces > - il n'y a pas de problème avec le logo de survol qui fonctionne bien avec les squelettes actuels lorsque la config "Utiliser les logos de survol" est activée > - Mieux : les problèmes signalés dans #4306 https://core.spip.net/issues/4306 et dûs à safehtml sont tous réglés. > > Peut être ces problèmes sont sensés se manifester seulement en mode parano ? Euh clairement les puces permettant un changement de statut rapide ne sont plus fonctionnelles (attribut onmouse* supprimés) coté privé, y compris sans mode parano (j'ai testé), une fois le plugin activé. Qu'on se comprenne bien : les puces de statut sont la, mais plus rien ne se passe quand on passe la souris dessus.

Ben si justement les puces marchent bien sur programmer avec htmlpurifier activé.

Tout semblait bien marcher mais pas sur une page les chevrons sont échappés dans une balise cadre dans le public, aussi bien avec htmlpurifier que sans semble t il : https://programmer.spip.net/spip.php?page=ticket&id_ticket=348 mais pas dans le privé où le rendu est parfait : https://programmer.spip.net/ecrire/?exec=article&id_article=128

Ben si justement les puces marchent bien sur programmer avec htmlpurifier activé. Tout semblait bien marcher mais pas sur une page les chevrons sont échappés dans une balise cadre dans le public, aussi bien avec htmlpurifier que sans semble t il : https://programmer.spip.net/spip.php?page=ticket&id_ticket=348 mais pas dans le privé où le rendu est parfait : https://programmer.spip.net/ecrire/?exec=article&id_article=128

Par contre le même article passe bien dans le carnet de contrib https://contrib.spip.net/test-safehtml

Par contre le même article passe bien dans le carnet de contrib https://contrib.spip.net/test-safehtml

jluc - a écrit :

Ben si justement les puces marchent bien sur programmer avec htmlpurifier activé.
Encore une fois, ce n'est pas normal #PUCE_STATUT passe dans typo/propre et l'attribut onmonseouver se retrouve filtré (comportement attendu), il y a peut être un traitement spécifique sur programmer.

Tout semblait bien marcher mais pas sur une page les chevrons sont échappés dans une balise cadre dans le public, aussi bien avec htmlpurifier que sans semble t il : https://programmer.spip.net/spip.php?page=ticket&id_ticket=348 mais pas dans le privé où le rendu est parfait : https://programmer.spip.net/ecrire/?exec=article&id_article=128

C'est "normal" parce que j'imagine que le mode parano est inactif, donc pas de filtrage coté public. Il doit être actif pour avoir l'équivalent coté public. Ce bug n'a a mon sens aucun rapport avec le plugin puisque

"aussi bien avec htmlpurifier que sans".

Et dans le carnet j'imagine que c'est filtré tout le temps "cause mode wiki".

Le problème doit venir d'un filtrage textwheel ou du core appliqué sur < et > pour des raisons de sécurité mais en dehors de safehtml()/du mode parano : il n'y pas de filtrage mais un peu quand même (sécurité <?php, ce genre de choses)....

J'ai testé `home (spip 3.2 à jour avec htmlPurifier) et pas de soucis pour afficher https://programmer.spip.net/spip.php?page=ticket&id_ticket=348 coté privé ou public.

jluc - a écrit : > Ben si justement les puces marchent bien sur programmer avec htmlpurifier activé. Encore une fois, ce n'est pas normal #PUCE_STATUT passe dans typo/propre et l'attribut onmonseouver se retrouve filtré (comportement attendu), il y a peut être un traitement spécifique sur programmer. > > Tout semblait bien marcher mais pas sur une page les chevrons sont échappés dans une balise cadre dans le public, aussi bien avec htmlpurifier que sans semble t il : https://programmer.spip.net/spip.php?page=ticket&id_ticket=348 mais pas dans le privé où le rendu est parfait : https://programmer.spip.net/ecrire/?exec=article&id_article=128 C'est "normal" parce que j'imagine que le mode parano est inactif, donc pas de filtrage coté public. Il doit être actif pour avoir l'équivalent coté public. Ce bug n'a a mon sens aucun rapport avec le plugin puisque > "aussi bien avec htmlpurifier que sans". Et dans le carnet j'imagine que c'est filtré tout le temps "cause mode wiki". Le problème doit venir d'un filtrage textwheel ou du core appliqué sur < et > pour des raisons de sécurité mais en dehors de safehtml()/du mode parano : il n'y pas de filtrage mais un peu quand même (sécurité <?php, ce genre de choses).... J'ai testé `home (spip 3.2 à jour avec htmlPurifier) et pas de soucis pour afficher https://programmer.spip.net/spip.php?page=ticket&id_ticket=348 coté privé ou public.
Owner

Salut

Pour note : je viens tomber sur ce script (maintenu) pour nettoyer simplement le html
http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/

Utiliser chez glpi si j'ai bien suivi

Salut Pour note : je viens tomber sur ce script (maintenu) pour nettoyer simplement le html http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/ Utiliser chez glpi si j'ai bien suivi

cam.lafit - a écrit :

Salut

Pour note : je viens tomber sur ce script (maintenu) pour nettoyer simplement le html
http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/

Utiliser chez glpi si j'ai bien suivi
Et plus récent dans sa dernière version que HTMLPurifier (dont la page qui compare les différentes libs ne compare qu'avec une très vieille version).

Et en plus, ça marche avec composer : http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/composer_usage.htm

Par contre, aucune des 2 libs n'est sur un repository affichant des diffs

cam.lafit - a écrit : > Salut > > Pour note : je viens tomber sur ce script (maintenu) pour nettoyer simplement le html > http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/ > > Utiliser chez glpi si j'ai bien suivi Et plus récent dans sa dernière version que HTMLPurifier (dont la page qui compare les différentes libs ne compare qu'avec une très vieille version). Et en plus, ça marche avec composer : http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/composer_usage.htm Par contre, aucune des 2 libs n'est sur un repository affichant des diffs

cam.lafit - a écrit :

Salut

Pour note : je viens tomber sur ce script (maintenu) pour nettoyer simplement le html
http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/

Utiliser chez glpi si j'ai bien suivi

Imo c'est vraiment tout ce qu'il faut éviter, pour rappel : ce n'est pas possible d'imaginer construire une libraire de filtrage à base de regexp/preg_match & co. L'utilisation d'un parser XML est obligatoire pour espérer faire le travail le plus correctement possible.

cam.lafit - a écrit : > Salut > > Pour note : je viens tomber sur ce script (maintenu) pour nettoyer simplement le html > http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/ > > Utiliser chez glpi si j'ai bien suivi Imo c'est vraiment tout ce qu'il faut éviter, pour rappel : ce n'est pas possible d'imaginer construire une libraire de filtrage à base de regexp/preg_match & co. L'utilisation d'un parser XML est obligatoire pour espérer faire le travail le plus correctement possible.

RealET 🔸 a écrit :

cam.lafit - a écrit :

Salut

Pour note : je viens tomber sur ce script (maintenu) pour nettoyer simplement le html
http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/

Utiliser chez glpi si j'ai bien suivi
Et plus récent dans sa dernière version que HTMLPurifier (dont la page qui compare les différentes libs ne compare qu'avec une très vieille version).

Et en plus, ça marche avec composer : http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/composer_usage.htm

Par contre, aucune des 2 libs n'est sur un repository affichant des diffs

Les différences sont claires, il suffit d'aller voir le code ^^' D'ailleurs ça se paye cash, je prend le premier motif d'injection sur https://html5sec.org/ et je test sur http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/htmLawedTest.php (avec safe=1 dans les settings) :

Input code :
<form id="test"></form><button form="test" formaction="javascript:alert(1)">X</button>

Output code :
<form id="test" action="action"></form><button form="test" formaction="javascript:alert(1)">X</button>

J'ai ri :] C'est pas plutôt htmFFFLawed cette librairie ?! ;-)

RealET 🔸 a écrit : > cam.lafit - a écrit : > > Salut > > > > Pour note : je viens tomber sur ce script (maintenu) pour nettoyer simplement le html > > http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/ > > > > Utiliser chez glpi si j'ai bien suivi > Et plus récent dans sa dernière version que HTMLPurifier (dont la page qui compare les différentes libs ne compare qu'avec une très vieille version). > > Et en plus, ça marche avec composer : http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/composer_usage.htm > > Par contre, aucune des 2 libs n'est sur un repository affichant des diffs Les différences sont claires, il suffit d'aller voir le code ^^' D'ailleurs ça se paye cash, je prend le premier motif d'injection sur https://html5sec.org/ et je test sur http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/htmLawedTest.php (avec safe=1 dans les settings) : Input code : `<form id="test"></form><button form="test" formaction="javascript:alert(1)">X</button>` Output code : `<form id="test" action="action"></form><button form="test" formaction="javascript:alert(1)">X</button>` J'ai ri :] C'est pas plutôt htmFFFLawed cette librairie ?! ;-)

Est ce qu'on peut maintenant le mettre dans la version "spip 3.3 dev" en remplaçement de safehtml ? Puis on le testerai jusqu'à la release de la 3.4 si pas de pb par exemple.

Au final ce qu'il faut tester ce n'est pas tant la nouvelle librairie (qui doit quand même faire son taf) que les surcharges de textwheel (règles YAML, fonctions de filtrage associées et la modification dans propre()`inc/texte.php qui inverse l'ordre de echappe_html() et echappe_html_suspect().

Pour rappel : ça n'impacte que le /ecrire/ pour les sites sans mode parano.

Si des propriétaire de Spip avec $filtrer_javascript=-1 peuvent tester ce serait bien.
Version cible mise à 4.0

Est ce qu'on peut maintenant le mettre dans la version "spip 3.3 dev" en remplaçement de safehtml ? Puis on le testerai jusqu'à la release de la 3.4 si pas de pb par exemple. Au final ce qu'il faut tester ce n'est pas tant la nouvelle librairie (qui doit quand même faire son taf) que les surcharges de textwheel (règles YAML, fonctions de filtrage associées et la modification dans propre()`inc/texte.php qui inverse l'ordre de echappe_html() et echappe_html_suspect(). Pour rappel : ça n'impacte que le /ecrire/ pour les sites sans mode parano. Si des propriétaire de Spip avec $filtrer_javascript=-1 peuvent tester ce serait bien. **Version cible mise à 4.0**

Parce que j'avais un peu oublié cet aspect: le mode parano est cassé/inefficient depuis très (très très ?) longtemps https://core.spip.net/projects/spip/repository/revisions/24064 (et j'ai l'impression que personne ne s'en ai jamais plaint alors que c'était pourtant très impactant lorsque filtrage indispensable).

Autant dire que le remplacement de safehtml par htmlpurifier ne devrait gêner aucun utilisateur (y en a t il seulement ?) du mode parano qui :

  • avant ce patch, n'avait pas un système effectif niveau sécurité
  • après ce patch, se retrouve avec une mise en forme par propre() non fonctionnelle coté public (coté privé typo() utilise le bon ordre avec echappe_html() puis echappe_html_suspect().

Avec le mode parano inactif, le filtrage n'est donc appliqué que dans /ecrire/ (et sur certains éléments spécifique à protéger coté public, les forums par exemple). Beaucoup de tests/vérification ont déjà) été faites sur l'espace privé 3.2, et (hors puce) aucun problème de mise en forme a été identifié ; c'est même le contraire, beaucoup de problème de mise en forme réglés (le filtrage par liste noire dans textwheel introduisant des bugs).

Il peux rester d'éventuels bugs dans /ecrire/ liés a des plugins qui générerait du code HTML non conforme mais cela me semble peu probable (bcp moins que coté public) et doit de toute façon être corrigé.

Le site https://programmer.spip.net/ utilise htmlPurifier pour test (mode parano inactif) : pas de problème identifié dans l'espace privé :)))

Parce que j'avais un peu oublié cet aspect: le mode parano est cassé/inefficient depuis très (très très ?) longtemps https://core.spip.net/projects/spip/repository/revisions/24064 (et j'ai l'impression que personne ne s'en ai jamais plaint alors que c'était pourtant très impactant lorsque filtrage indispensable). Autant dire que le remplacement de safehtml par htmlpurifier ne devrait gêner aucun utilisateur (y en a t il seulement ?) du mode parano qui : - avant ce patch, n'avait pas un système effectif niveau sécurité - après ce patch, se retrouve avec une mise en forme par propre() non fonctionnelle coté public (coté privé typo() utilise le bon ordre avec echappe_html() puis echappe_html_suspect(). Avec le mode parano inactif, le filtrage n'est donc appliqué que dans /ecrire/ (et sur certains éléments spécifique à protéger coté public, les forums par exemple). Beaucoup de tests/vérification ont déjà) été faites sur l'espace privé 3.2, et (hors puce) aucun problème de mise en forme a été identifié ; c'est même le contraire, beaucoup de problème de mise en forme réglés (le filtrage par liste noire dans textwheel introduisant des bugs). Il peux rester d'éventuels bugs dans /ecrire/ liés a des plugins qui générerait du code HTML non conforme mais cela me semble peu probable (bcp moins que coté public) et doit de toute façon être corrigé. Le site https://programmer.spip.net/ utilise htmlPurifier pour test (mode parano inactif) : pas de problème identifié dans l'espace privé :)))
Poster

Hello :-)
Ne ne faudrait-il pas le mettre dans la 3.3, sortir la version en alpha1 et suivant les retours prendre une décision une fois pour toute ?
Car là, nous n'avons que https://programmer.spip.net qui permet de faire des tests

Surtout que à l'annonce de spip 3.3 alpha1, il est toujours possible de mettre en avant qu'il peut encore y avoir du changement d'ici la sortie de la version "stable"

Hello :-) Ne ne faudrait-il pas le mettre dans la 3.3, sortir la version en alpha1 et suivant les retours prendre une décision une fois pour toute ? Car là, nous n'avons que https://programmer.spip.net qui permet de faire des tests Surtout que à l'annonce de spip 3.3 alpha1, il est toujours possible de mettre en avant qu'il peut encore y avoir du changement d'ici la sortie de la version "stable"

Autre endroit pour faire des tests : https://www.root-me.org/ avec un spip3.2 uptodate, (les "joueurs" font déjà bcp de tests ^^)

Sinon oui, je plussoie pour l'intégrer en 3.3 alpha et voir si ça coince encore a certains endroits.

Autre endroit pour faire des tests : https://www.root-me.org/ avec un spip3.2 uptodate, (les "joueurs" font déjà bcp de tests ^^) Sinon oui, je plussoie pour l'intégrer en 3.3 alpha et voir si ça coince encore a certains endroits.

À ce propos Guillaume, est-ce que tu pourrais mettre à jour la version HTML5 pour prendre en compte https://zone.spip.net/trac/spip-zone/changeset/115979/spip-zone

Merci

À ce propos Guillaume, est-ce que tu pourrais mettre à jour la version HTML5 pour prendre en compte https://zone.spip.net/trac/spip-zone/changeset/115979/spip-zone Merci

RealET 🔸 a écrit :

À ce propos Guillaume, est-ce que tu pourrais mettre à jour la version HTML5 pour prendre en compte https://zone.spip.net/trac/spip-zone/changeset/115979/spip-zone

Merci

Ok a l'occase j'essaye de faire ca (j'ai tenté rapidement sans succès :p). A priori il s'agit d'améliorer la compat PHP 7.3, je suis actuellement en 7.2 sans problème.

RealET 🔸 a écrit : > À ce propos Guillaume, est-ce que tu pourrais mettre à jour la version HTML5 pour prendre en compte https://zone.spip.net/trac/spip-zone/changeset/115979/spip-zone > > Merci Ok a l'occase j'essaye de faire ca (j'ai tenté rapidement sans succès :p). A priori il s'agit d'améliorer la compat PHP 7.3, je suis actuellement en 7.2 sans problème.

Une version propre amha des défintions HTML5 nécessaire pour avoir un parser html5 avec htmlpurifier : https://github.com/xemlock/htmlpurifier-html5

A vocation a remplacer mon "bricolage" si complet et fonctionnel.

EDIT : pour avoir repris un peu le sujet, le bricolage en question était pas si bête puisqu'il s'agit déjà d'un merge de htmlpurifier + htmlpurifier-html5 + modifications pour coller au mieux à la norme.

Une version propre amha des défintions HTML5 nécessaire pour avoir un parser html5 avec htmlpurifier : https://github.com/xemlock/htmlpurifier-html5 A vocation a remplacer mon "bricolage" si complet et fonctionnel. EDIT : pour avoir repris un peu le sujet, le bricolage en question était pas si bête puisqu'il s'agit déjà d'un merge de htmlpurifier + htmlpurifier-html5 + modifications pour coller au mieux à la norme.
Owner

toujours pour "plus tard"
Version cible mise à 4.1

toujours pour "plus tard" **Version cible mise à 4.1**
Owner

Bon, malheureusement certainement, ça ne sera pas dans cette version 4.0
Croisons les doigts pour une prochaine version, pas trop lointaine :)

Bon, malheureusement certainement, ça ne sera pas dans cette version 4.0 Croisons les doigts pour une prochaine version, pas trop lointaine :)

Qu'est ce qu'il manquerait actuellement pour intégrer HtmlPurifier ?

Qu'est ce qu'il manquerait actuellement pour intégrer HtmlPurifier ?
Owner
Voir aussi https://github.com/tgalopin/html-sanitizer
Owner

Voir aussi https://github.com/tgalopin/html-sanitizer

Ouep, cf la description de la différence avec htmlpurifier qui semble plus convenir à notre usage :

html-sanitizer is much stricter and does not try to fix the HTML provided. Instead, it builds new HTML from scratch by extracting only the safe data from the input. It aims to be used in combination with a WYSIWYG / client-side editor that output valid HTML: if the provided HTML was badly written, it means someone is trying to do something evil and the sanitizer can simply remove the invalid parts entirely.

https://github.com/tgalopin/html-sanitizer/blob/master/docs/4-comparison-with-htmlpurifier.md

> Voir aussi https://github.com/tgalopin/html-sanitizer Ouep, cf la description de la différence avec htmlpurifier qui semble plus convenir à notre usage : > html-sanitizer is much stricter and does not try to fix the HTML provided. Instead, it builds new HTML from scratch by extracting only the safe data from the input. It aims to be used in combination with a WYSIWYG / client-side editor that output valid HTML: if the provided HTML was badly written, it means someone is trying to do something evil and the sanitizer can simply remove the invalid parts entirely. https://github.com/tgalopin/html-sanitizer/blob/master/docs/4-comparison-with-htmlpurifier.md
Owner
et https://github.com/symfony/html-sanitizer
Owner

ce projet semble séduisant mais on va se retrouver avec la (récurrente) question de sa dépendance à Composer pour son installation/MàJ :
https://github.com/tgalopin/html-sanitizer/blob/master/docs/1-getting-started.md#installation dit :

You can install the library using the following command:

composer require tgalopin/html-sanitizer

une idée de la tactique possible pour gérer ça d'ici que SPIP passe à Composer ?

ce projet semble séduisant mais on va se retrouver avec la (récurrente) question de sa dépendance à Composer pour son installation/MàJ : https://github.com/tgalopin/html-sanitizer/blob/master/docs/1-getting-started.md#installation dit : > You can install the library using the following command: ``` composer require tgalopin/html-sanitizer ``` une idée de la tactique possible pour gérer ça d'ici que SPIP passe à Composer ?

une idée de la tactique possible pour gérer ça d'ici que SPIP passe à Composer ?

Tout comme pour l'instant, en l'incluant le résultat tel quel ?
Sauf que la lib a elle-même des require dont psr/log qui est un peu commun.

Pour l'instant je pense à deux choses 👍:

  1. on n'est pas si loin que ça de pouvoir utiliser composer pour le core, donc si on va au bout, on va vraiment pouvoir require ce qu'on veut pour le noyau, qui ira dans un vendor racine et qui sera recopié pour l'empaquetage ZIP des gens qui installent comme avant (ya une todo list des tâches restantes pour aboutir à composer pour le core, dans un ticket ?)
  2. le plugin-dist safehtml ne servait qu'à encapsuler la lib désormais très naze du même nom, et presque rien d'autre : une fois qu'on décide de ne plus l'utiliser, je propose de remettre cette fonctionnalité directement dans le core pour pouvoir en dépendre en require depuis le composer.json du core

Avec ça on aurait moyen de choisir la lib la plus à jour moderne qu'on veut (par ex cette dernière), directement en composer depuis le core.

> une idée de la tactique possible pour gérer ça d'ici que SPIP passe à Composer ? Tout comme pour l'instant, en l'incluant le résultat tel quel ? Sauf que la lib a elle-même des require dont psr/log qui est un peu commun. Pour l'instant je pense à deux choses 👍: 1) on n'est pas si loin que ça de pouvoir utiliser composer **pour le core**, donc si on va au bout, on va vraiment pouvoir require **ce qu'on veut** pour le noyau, qui ira dans un vendor racine et qui sera recopié pour l'empaquetage ZIP des gens qui installent comme avant (ya une todo list des tâches restantes pour aboutir à composer pour le core, dans un ticket ?) 2) le plugin-dist safehtml ne servait qu'à encapsuler la lib désormais très naze du même nom, et presque rien d'autre : une fois qu'on décide de ne plus l'utiliser, je propose de remettre cette fonctionnalité directement dans le core **pour pouvoir en dépendre en require depuis le composer.json du core** Avec ça on aurait moyen de choisir la lib la plus à jour moderne qu'on veut (par ex cette dernière), directement en composer depuis le core.
Owner

Bon j'ai mis le nez dans le plugin HtmlPurifier et pour moi c'est pas du tout utilisable as is pour les raisons que j'expose là
spip-contrib-extensions/htmlpurifier#2

Dans le core on veut surtout éviter de faire passer tous les contenus dans purifier ou safehtml car c'est très lent et cela va impacter énormément la perf de SPIP

Bon j'ai mis le nez dans le plugin HtmlPurifier et pour moi c'est pas du tout utilisable as is pour les raisons que j'expose là https://git.spip.net/spip-contrib-extensions/htmlpurifier/issues/2#issuecomment-39582 Dans le core on veut surtout éviter de faire passer tous les contenus dans purifier ou safehtml car c'est très lent et cela va impacter énormément la perf de SPIP
Owner

@cerdic merci pour l'analyse et le compte rendu :)

@cerdic merci pour l'analyse et le compte rendu :)
Owner

C'est dans la boite pour la future 4.2, on ferme.

PS : on y reviendra plus tard cf les échanges sur spip/safehtml#4781 & spip/safehtml#4783

C'est dans la boite pour la future 4.2, on ferme. PS : on y reviendra plus tard cf les échanges sur https://git.spip.net/spip/safehtml/pulls/4781 & https://git.spip.net/spip/safehtml/pulls/4783
b_b closed this issue 3 months ago
Sign in to join this conversation.
No Milestone
No project
No Assignees
10 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.