safehtml vire des trucs légitimes #4706

Closed
opened 2 years ago by rastapopoulos · 38 comments
Owner

Il semblerait que safehtml fasse quelque peu de la merde : ça vire des attributs totalement légitimes, par ex des data-truc où on met ce qu'on veut.
En 3.2 ou 3.3, à corriger dans les deux.

Par exemple le plugin Intl qui a une fonction d'affichage des montants, utilise le mot "montant" dans des attributs (logique vu que c'est tout l'objet du plugin).

J'ai bien testé avec juste charger_fonction('safehtml', 'inc') de ce plugin.

$safehtml('<span class="montant" data-montant-nombre="100" data-montant-devise="EUR">')

Au retour ya plus que :

<span class="montant"

Et du coup ça affiche l'emoji danger avec le code visible, par exemple dans des affichages du plugin Bank, mais pas que, dès qu'on passe ce HTML à une chaine de langue un truc comme ça.

Il semblerait que safehtml fasse quelque peu de la merde : ça vire des attributs totalement légitimes, par ex des data-truc où on met ce qu'on veut. En 3.2 ou 3.3, à corriger dans les deux. Par exemple le plugin Intl qui a une fonction d'affichage des montants, utilise le mot "montant" dans des attributs (logique vu que c'est tout l'objet du plugin). J'ai bien testé avec juste charger_fonction('safehtml', 'inc') de ce plugin. ``` $safehtml('<span class="montant" data-montant-nombre="100" data-montant-devise="EUR">') ``` Au retour ya plus que : ``` <span class="montant" ``` Et du coup ça affiche l'emoji danger avec le code visible, par exemple dans des affichages du plugin Bank, mais pas que, dès qu'on passe ce HTML à une chaine de langue un truc comme ça.
Poster
Owner
There is no content yet.
Owner

Plutôt que de corriger cette lib qui vieillit, il faudrait passer à html purifier ...
https://core.spip.net/issues/3926

Plutôt que de corriger cette lib qui vieillit, il faudrait passer à html purifier ... https://core.spip.net/issues/3926
Poster
Owner

Ça sera sûrement mieux oui, par contre j'ai mis 3.2 car ça va resté maintenu et stable un moment quand même (même après 3.3 sorti), et donc tous les gens qui ont un site avec de la vente (ou des dons) et qui sont en 3.2, s'ils mettent juste à jour leurs plugins régulièrement, bah ils vont tous avoir certains affichages pétés (puisque désormais Prix/Intl génère ce HTML avec des data persos, et que cet affichage de montant peut être passé à des chaines de langue, comme dans Bank notamment mais pas que).

Ça sera sûrement mieux oui, par contre j'ai mis 3.2 car ça va resté maintenu et stable un moment quand même (même après 3.3 sorti), et donc tous les gens qui ont un site avec de la vente (ou des dons) et qui sont en 3.2, s'ils mettent juste à jour leurs plugins régulièrement, bah ils vont tous avoir certains affichages pétés (puisque désormais Prix/Intl génère ce HTML avec des data persos, et que cet affichage de montant peut être passé à des chaines de langue, comme dans Bank notamment mais pas que).
Poster
Owner

Pour résoudre sans changer de lib (donc y compris 3.2), il faudrait modifier la lib safehtml() pour que ça ne supprime au moins aucun data-truc qui sont dans tous les cas totalement légitimes. La lib a été faite à un moment où ça n'existait (fort longtemps donc), mais maintenant il y en a un peu partout des data-truc.

Pour résoudre sans changer de lib (donc y compris 3.2), il faudrait modifier la lib safehtml() pour que ça ne supprime au moins aucun data-truc qui sont dans tous les cas totalement légitimes. La lib a été faite à un moment où ça n'existait (fort longtemps donc), mais maintenant il y en a un peu partout des data-truc.

Bonjour,

Je me permets de faire un lien vers une observation du ticket concernant l'utilisation de la balise < pre > avec les attributs data- qui disparaissent (https://core.spip.net/issues/3990#note-8).

Bonjour, Je me permets de faire un lien vers une observation du ticket concernant l'utilisation de la balise < pre > avec les attributs data- qui disparaissent (https://core.spip.net/issues/3990#note-8).
Owner

J'ai du mal à me faire un avis sur ces attributs data-.

Dans ton cas Rasta, le code ajouté ne provient pas d'une saisie utilisateur, pourquoi alors passer par safehtml() ?
Est-ce qu'on a pas moyen de dire que "je sais que mon code html que j'ajoute est valide / ok" : c'est le cas si on ajoute des modèles il me semble.

Mais si on considère que les attributs data- sont utilisés derrière en JS pour charger des trucs divers s'ils sont présents, c'est peut être pas faux de les brider dans les saisies utilisateurs…
Bref, tout ça me questionne !

J'ai du mal à me faire un avis sur ces attributs data-. Dans ton cas Rasta, le code ajouté ne provient pas d'une saisie utilisateur, pourquoi alors passer par safehtml() ? Est-ce qu'on a pas moyen de dire que "je sais que mon code html que j'ajoute est valide / ok" : c'est le cas si on ajoute des modèles il me semble. Mais si on considère que les attributs data- sont utilisés derrière en JS pour charger des trucs divers s'ils sont présents, c'est peut être pas faux de les brider dans les saisies utilisateurs… Bref, tout ça me questionne !
Poster
Owner

Mais moi je passe nulle part, c'est les chaines de langue qui y passent automatiquement (sanitize=true par défaut).

Mais quand même ça n'y passe que pour les arguments. Sauf que là le HTML c'est dans une chaine de langue du plugin Intl certes, mais qui ensuite est inséré en argument dans une chaine de langue du plugin Bank, de mémoire. Genre une phrase qui inclut un montant formaté dedans (#MONTANT|montant_formater en gros).

En attendant il faudrait au moins que Bank ajoute un sanitize=false sur cette appel, un truc comme ça.

Mais moi je passe nulle part, c'est les chaines de langue qui y passent automatiquement (sanitize=true par défaut). Mais quand même ça n'y passe que pour les arguments. Sauf que là le HTML c'est dans une chaine de langue du plugin Intl certes, mais qui ensuite est inséré *en argument* dans une chaine de langue du plugin Bank, de mémoire. Genre une phrase qui inclut un montant formaté dedans (#MONTANT|montant_formater en gros). En attendant il faudrait au moins que Bank ajoute un sanitize=false sur cette appel, un truc comme ça.

Autre cas problématique : la prévisualisation des slides avec nivoslider : https://contrib.spip.net/Nivo-Slider-3747#comment508245-508242

Autre cas problématique : la prévisualisation des slides avec nivoslider : https://contrib.spip.net/Nivo-Slider-3747#comment508245-508242
Owner

ça vaut ce que ça vaut, mais j'ai mis la lib a jour et introduit des tests unitaires
https://git.spip.net/spip/safehtml/commits/branch/master

ça vaut ce que ça vaut, mais j'ai mis la lib a jour et introduit des tests unitaires https://git.spip.net/spip/safehtml/commits/branch/master
Owner

Et avec les tests unitaires, tout va mieux : c'est donc corrigé en 4.0-dev par ad3f445ec8
(je sais pas si il faut reporter en 3.2, je suis pas certain certain)

Et par contre RealET, ton url en data:xxx est un cas légitime et potentiellement dangereux, il est donc normal que safehlml la supprime, ne t'en déplaise
Version cible mise à 4.0
Statut changé à Fermé

Et avec les tests unitaires, tout va mieux : c'est donc corrigé en 4.0-dev par https://git.spip.net/spip/safehtml/commit/ad3f445ec89181bafd31ed82726810b17f77bd91 (je sais pas si il faut reporter en 3.2, je suis pas certain certain) Et par contre RealET, ton url en data:xxx est un cas légitime et potentiellement dangereux, il est donc normal que safehlml la supprime, ne t'en déplaise **Version cible mise à 4.0** **Statut changé à Fermé**
Poster
Owner

excellent merci !

excellent merci !

cedric - a écrit :

Et par contre RealET, ton url en data:xxx est un cas légitime et potentiellement dangereux, il est donc normal que safehlml la supprime, ne t'en déplaise

Super, merci.

Et pour NivoSlider, c'est résolu : https://git.spip.net/spip-contrib-extensions/nivoslider/commit/2fc16f04

cedric - a écrit : > Et par contre RealET, ton url en data:xxx est un cas légitime et potentiellement dangereux, il est donc normal que safehlml la supprime, ne t'en déplaise Super, merci. Et pour NivoSlider, c'est résolu : https://git.spip.net/spip-contrib-extensions/nivoslider/commit/2fc16f04
Poster
Owner

`Cédric : est-ce qu'on peut discuter de si ça doit être reporté en 3.2 ?

En effet ça va être une LTS, et ce bug apparait dès aujourd'hui pour des sites en production, qui vont durer encore. Ce pourquoi j'avais bien mis ce ticket dès la 3.2.

`Cédric : est-ce qu'on peut discuter de si ça doit être reporté en 3.2 ? En effet ça va être une LTS, et ce bug apparait dès aujourd'hui pour des sites en production, qui vont durer encore. Ce pourquoi j'avais bien mis ce ticket dès la 3.2.
Poster
Owner

Je rouvre car la 3.2 sera LTS et que le rapport était en premier lieu pour cette version stable.
Version cible mise à 3.2
Statut changé à En cours

Je rouvre car la 3.2 sera LTS et que le rapport était en premier lieu pour cette version stable. **Version cible mise à 3.2** **Statut changé à En cours**
b_b commented 1 year ago
Owner

+1 pour un report en 3.2, comme je le disais sur IRC, amha on peut reporter les trucs simples et fonctionnels sur la 3.2 jusqu'à la prochaine release de 4.x (ou 5) prévue cet hiver. Après cette date, il sera temps d'acter qu'on ne fait plus que des reports de sécu vers la 3.2, sans quoi on se posera toujours cette question :)
Version cible mise à 4.0

+1 pour un report en 3.2, comme je le disais sur IRC, amha on peut reporter les trucs simples et fonctionnels sur la 3.2 jusqu'à la prochaine release de 4.x (ou 5) prévue cet hiver. Après cette date, il sera temps d'acter qu'on ne fait plus que des reports de sécu vers la 3.2, sans quoi on se posera toujours cette question :) **Version cible mise à 4.0**
b_b commented 1 year ago
Owner

Version cible mise à 3.2

**Version cible mise à 3.2**
Owner

Reporté en 3.2 via quelques cherry-pick …

Reporté en 3.2 via quelques cherry-pick …
b_b commented 1 year ago
Owner

Super, on ferme :)
Statut changé à Fermé

Super, on ferme :) **Statut changé à Fermé**
Poster
Owner

Hello,

Un utilisateur du plugin Prix et du plugin Bank, affirmant bien utiliser la toute dernière version de la branche : 3.2.14, signale qu'il a aussi ce même problème.
https://contrib.spip.net/Plugin-API-Prix#comment510477

Comment est-ce possible si la correction a bien été reportée en 3.2 ?

Hello, Un utilisateur du plugin Prix et du plugin Bank, affirmant bien utiliser la toute dernière version de la branche : 3.2.14, signale qu'il a aussi ce même problème. https://contrib.spip.net/Plugin-API-Prix#comment510477 Comment est-ce possible si la correction a bien été reportée en 3.2 ?
rastapopoulos reopened this issue 7 months ago
Poster
Owner

D'aucun disent que c'est toujours pété en 4.0 aussi (et donc sûrement en master aussi)

D'aucun disent que c'est toujours pété en 4.0 aussi (et donc sûrement en master aussi)
Owner

"D'aucun" confirme que oui, c'est toujours pété en SPIP 4.0.5 + Bank v5 :

"D'aucun" confirme que oui, c'est toujours pété en SPIP 4.0.5 + Bank v5 :
Owner

Allez un petit effort, vous êtes à deux doigts de fournir un test case reproductible qu'on peut intégrer dans la suite de test et fixer sans avoir à installer tonnes de plugins et jouer aux devinettes...

Allez un petit effort, vous êtes à deux doigts de fournir un test case reproductible qu'on peut intégrer dans la suite de test et fixer sans avoir à installer tonnes de plugins et jouer aux devinettes...
Poster
Owner

Bé le code auto-suffisant est littéralement juste dans le message précédent du tien… :)

echo $safehtml('<span class="montant" datamontant-nombre="6.5" data-montant-devise="EUR">6,50 <span class="montant__devise">EUR</span><meta itemprop="price" content="6.5" /><meta itemprop="priceCurrency" content="EUR" /></span>');

=> Les balises <meta itemprop=… content=… sont totalement supprimées (alors qu'il faut évidemment qu'elles soient là pour les microformats). Là aussi c'est du HTML parfaitement légitime (microformat schema.org). Et dès que safehtml() ne sort pas pareil que le texte de base, ça affiche l'emoji danger le HTML en clair.

Bé le code auto-suffisant est littéralement juste dans le message précédent du tien… :) ```php echo $safehtml('<span class="montant" datamontant-nombre="6.5" data-montant-devise="EUR">6,50 <span class="montant__devise">EUR</span><meta itemprop="price" content="6.5" /><meta itemprop="priceCurrency" content="EUR" /></span>'); ``` => Les balises `<meta itemprop=… content=…` sont totalement supprimées (alors qu'il faut évidemment qu'elles soient là pour les microformats). Là aussi c'est du HTML parfaitement légitime (microformat schema.org). Et dès que safehtml() ne sort pas pareil que le texte de base, ça affiche l'emoji danger le HTML en clair.
Poster
Owner

(Cette lib n'est vraiment vraiment plus raccord avec le HTML5 de nos jours… :'( )

Je disais :

La lib a été faite à un moment où ça n'existait (fort longtemps donc), mais maintenant il y en a un peu partout des data-truc.

Mais c'est pareil pour les microformats (itemprop, etc), bien officiels dans HTML5 et qu'on trouve un peu partout désormais.

(Cette lib n'est vraiment vraiment plus raccord avec le HTML5 de nos jours… :'( ) Je disais : > La lib a été faite à un moment où ça n'existait (fort longtemps donc), mais maintenant il y en a un peu partout des data-truc. Mais c'est pareil pour les microformats (itemprop, etc), [bien officiels dans HTML5](https://developer.mozilla.org/fr/docs/Web/HTML/Global_attributes/itemprop) et qu'on trouve un peu partout désormais.
Poster
Owner

Et donc ça a effectivement marché pendant plusieurs mois, puisqu'il n'y avait pas des microformats HTML5 au moment de la première correction. Ça a été ajouté par @tcharlss ya 4 mois ici : 248e9b9c01

Ce qui a re-pété depuis ce moment car ça utilise des attributs html5 récents de nouveau non reconnus tout comme les data-truc (qui sont cependant toujours aussi légitimes, et on aura ce problème à chaque fois qu'un nouvel attribut html5 se retrouvera dans safehtml).

Et donc ça a effectivement marché pendant plusieurs mois, puisqu'il n'y avait pas des microformats HTML5 au moment de la première correction. Ça a été ajouté par @tcharlss ya 4 mois ici : https://git.spip.net/spip-contrib-extensions/intl/commit/248e9b9c01bb61d44a7cb733da1338d8c87d6f52 Ce qui a re-pété depuis ce moment car ça utilise des attributs html5 récents de nouveau non reconnus tout comme les data-truc (qui sont cependant toujours aussi légitimes, et on aura ce problème à chaque fois qu'un nouvel attribut html5 se retrouvera dans safehtml).
Owner
Voir aussi https://github.com/tgalopin/html-sanitizer
Owner
Et https://github.com/symfony/html-sanitizer
Poster
Owner

En lien avec #3926 donc

En lien avec https://git.spip.net/spip/spip/issues/3926 donc
b_b commented 1 month ago
Owner

Maintenant que htmlpurifier est intégré dans la future 4.2, est-ce qu'on peut fermer ce ticket ?

Maintenant que htmlpurifier est intégré dans la future 4.2, est-ce qu'on peut fermer ce ticket ?
Poster
Owner

Pour l'instant ma réponse à moi c'est : j'espère ! 😛

Mais donc faut tester sur les cas d'exemples qui sont du HTML5 bien valide : des "data-truc" + des microformats avec "itemprop=" etc, et que SPIP ne supprime rien de tout ça (pour tester, ya tout ce qui est généré par le plugin Prix enfin Intl, avec montant_afficher)

Pour l'instant ma réponse à moi c'est : j'espère ! 😛 Mais donc faut tester sur les cas d'exemples qui sont du HTML5 bien valide : des "data-truc" + des microformats avec "itemprop=" etc, et que SPIP ne supprime rien de tout ça (pour tester, ya tout ce qui est généré par le plugin Prix enfin Intl, avec montant_afficher)
b_b commented 1 month ago
Owner

Pour l'instant ma réponse à moi c'est : j'espère ! 😛

J'ai balancé une bonne base de test dans les tickets dédiés et pour moi c'est bon pour le futur. Le support de la 3.2 arrivant bientôt à son terme, je doute qu'un changement de lib de safehtml vers htmlpurifier ait lieu, donc fermons en mode wontfix :)

> Pour l'instant ma réponse à moi c'est : j'espère ! 😛 J'ai balancé une bonne base de test dans les tickets dédiés et pour moi c'est bon pour le futur. Le support de la 3.2 arrivant bientôt à son terme, je doute qu'un changement de lib de safehtml vers htmlpurifier ait lieu, donc fermons en mode wontfix :)
b_b added the
refusé
label 1 month ago
b_b closed this issue 1 month ago
Poster
Owner

Du coup pour être clair, la correction pour tous les sites qui ont du HTML5 (parfaitement légitime) par ci par là dans des contenus qui passent dans safehtml : c'est que en 4.2 pour l'instant c'est ça ? Et du coup en prod en 4.0 et 4.1 si on a du HTML5 parfois c'est toujours pété ?

Vu que @b_b dit au dessus avec raison que 3.2 à terme et que ça on s'en fout OK. Mais 4.0 et 4.1 sont pas corrigés du tout pour ce ticket, et pourtant bien supporté non ? Donc pourquoi wontfix ?

Du coup pour être clair, la correction pour tous les sites qui ont du HTML5 (parfaitement légitime) par ci par là dans des contenus qui passent dans safehtml : c'est que en 4.2 pour l'instant c'est ça ? Et du coup en prod en 4.0 et 4.1 si on a du HTML5 parfois c'est toujours pété ? Vu que @b_b dit au dessus avec raison que 3.2 à terme et que ça on s'en fout OK. Mais 4.0 et 4.1 sont pas corrigés du tout pour ce ticket, et pourtant bien supporté non ? Donc pourquoi wontfix ?
b_b commented 3 days ago
Owner

Donc pourquoi wontfix ?

Parce que l'intégration de html purifier ne me semble pas "reportable" en 4.1, mais peut-être que d'autres penseront le contraire.

> Donc pourquoi wontfix ? Parce que l'intégration de html purifier ne me semble pas "reportable" en 4.1, mais peut-être que d'autres penseront le contraire.
Owner

@rastapopoulos parce que il y a personne qui a une solution à apporter pour patcher la vieille safehtml() qui en effet supprime les balises <meta> qui sont potentiellement dangereuses.
https://git.spip.net/spip/safehtml/src/branch/3.0/lib/safehtml/classes/safehtml.php#L132
et qu'on va pas "juste laisser passer" les <meta> dans safehtml() pour les beaux yeux du plugin bank+intl qui concerne quelques utilisateurs, dans l'espace privé.

Mon avis perso est que le plugin intl devrait gérer ça avec un markup plus compliant en version SPIP < 4.2, au moins dans l'espace privé vu que tout le monde se fiche d'avoir des microdata dans ecrire/ hein

Mais si tu as un patch acceptable te prives pas.

Dans un monde idéal on aurait un patch, mais dans le monde réel je pense qu'il faut se contenter de contourner en attendant la release d'une 4.2 qui apportera une solution plus propre.

On a trainé pendant des années avant de s'attaquer au problème de safehtml() et maintenant on a plus qu'à faire avec...

@rastapopoulos parce que il y a personne qui a une solution à apporter pour patcher la vieille `safehtml()` qui en effet supprime les balises `<meta>` qui sont potentiellement dangereuses. https://git.spip.net/spip/safehtml/src/branch/3.0/lib/safehtml/classes/safehtml.php#L132 et qu'on va pas "juste laisser passer" les `<meta>` dans safehtml() pour les beaux yeux du plugin bank+intl qui concerne quelques utilisateurs, dans l'espace privé. Mon avis perso est que le plugin intl devrait gérer ça avec un markup plus compliant en version SPIP < 4.2, au moins dans l'espace privé vu que tout le monde se fiche d'avoir des microdata dans `ecrire/` hein Mais si tu as un patch acceptable te prives pas. Dans un monde idéal on aurait un patch, mais dans le monde réel je pense qu'il faut se contenter de contourner en attendant la release d'une 4.2 qui apportera une solution plus propre. On a trainé pendant des années avant de s'attaquer au problème de `safehtml()` et maintenant on a plus qu'à faire avec...
Poster
Owner

Je ne comprends pas pourquoi tu parles de l'espace privé… (où là on s'en fiche et on pourrait possiblement faire un patch à l'arrache). La plupart des retours qu'il y a concerne bien ce qui est généré par bank dans les forms/boutons publics des gens, puisqu'on y passe des montants générés internationalement suivant la config, en paramètre de chaine de langues du plugin Bank, qui du coup passent dans safehtml de base. C'est ça le problème, pas du tout l'admin.

Sauf que le plugin Intl ou Prix ne peut pas deviner magiquement au moment de la génération de l'affichage du montant pour quelle utilisation c'est ensuite. C'est donc pour moi bien au module, au code, qui utilise ce montant de s'assurer qu'il est correct à l'endroit du besoin où il est utilisé. Et donc… bien au plugin Bank de le faire pour ce qui nous concerne ici.

Comme expliqué ici : spip-contrib-extensions/intl#5

  • Soit il faudrait désactiver le sanitize à false dans les chaines de langue où le plugin met lui-même un #GET qu'il controle dedans (donc il sait que le param de chaine est sûr et donc il peut ne pas sanitize)
  • Soit il faut nettoyer le #GET du montant en amont juste avant, en le nettoyant pour être sûr qu'il va pas péter la chaine de langue ensuite (par ex en virant les balises complètement si on affirmer que dans le label d'un bouton de toute façon on veut juste le texte brut final)
Je ne comprends pas pourquoi tu parles de l'espace privé… (où là on s'en fiche et on pourrait possiblement faire un patch à l'arrache). La plupart des retours qu'il y a concerne bien ce qui est généré par bank *dans les forms/boutons publics des gens*, puisqu'on y passe des montants générés internationalement suivant la config, en paramètre de chaine de langues du plugin Bank, qui du coup passent dans safehtml de base. C'est ça le problème, pas du tout l'admin. Sauf que le plugin Intl ou Prix ne peut pas deviner magiquement au moment de la génération de l'affichage du montant *pour quelle utilisation c'est ensuite*. C'est donc pour moi bien au module, au code, qui *utilise ce montant* de s'assurer qu'il est correct à l'endroit du besoin où il est utilisé. Et donc… bien au plugin Bank de le faire pour ce qui nous concerne ici. Comme expliqué ici : https://git.spip.net/spip-contrib-extensions/intl/pulls/5#issuecomment-34331 - Soit il faudrait désactiver le sanitize à false dans les chaines de langue où le plugin met lui-même un #GET qu'il controle dedans (donc il sait que le param de chaine est sûr et donc il peut ne pas sanitize) - Soit il faut nettoyer le #GET du montant en amont juste avant, en le nettoyant pour être sûr qu'il va pas péter la chaine de langue ensuite (par ex en virant les balises complètement si on affirmer que dans le label d'un bouton de toute façon on veut juste le texte brut final)
Owner

Parce que dans ce ticket ici la seule plainte concerne un screenshot dans l'espace privé. Mais bon ça ne change rien au fond, a part contourner le problème pour les versions SPIP jusqu'à 4.1 je vois pas trop de solution

Parce que dans ce ticket ici la seule plainte concerne un screenshot dans l'espace privé. Mais bon ça ne change rien au fond, a part contourner le problème pour les versions SPIP jusqu'à 4.1 je vois pas trop de solution
Poster
Owner

Je ne sais pas d'où sort cette fake news que "ici la seule plainte concerne l'espace privé"… alors que depuis le tout début du fil ya 2 ans, ça parle "des affichages du plugin Bank" ou n'importe quelle chaine de langue, càd ce qu'affiche ce plugin, essentiellement aux gens aux visiteurs, donc bien dans le site, notamment dans les formulaires et boutons de paiement, donc bien dans le site.

En expliquant bien que c'est parce que Bank passe en param de chaines de langue (qui ont sanitize=true par défaut), du contenu qui peut parfaitement contenir du HTML, et donc du HTML5 (que ce soit par Intl ou par toute autre personnalisation de la fonction de formatage).

Autrement dit :

  • le HTML5 produit, peut venir de Intl OU PAS
  • si on parle des montants précisément, dans la fonction de formatage elle-même, il est rigoureusement impossible de discriminer pour quelle utilisation ça doit servir ensuite une fois que c'est fini d'être généré
  • c'est donc au code parent utilisateur qui demande le montant, de s'assurer ensuite qu'il est utilisable dans une chaine de langue (soit en désactivant le sanitize, soit en nettoyant le param avant de le passer à la chaine)

La manière de contourner jusqu'à 4.1, devrait donc être de modifier les plugins qui parfois passent des choses qui peuvent contenir du HTML, en param de chaines de langue, c'est le cas de Bank mais possiblement d'autres plugins bien sûr.

Pour cela trois possibilité :

  • Soit il faut sanitize false dans les chaines, ce qui permet de bien garder le markup
    [(#VAL{bankouautre:whateverchaine}|_T{
      #ARRAY{montant, #GET{montant}},
      #ARRAY{sanitize, ''}
    }|propre)]
    
  • Soit il faut nettoyer le param avant, par ex
    #SET{param, #GET{param}|supprimer_tags}
    <:bankouautre:whateverchaine{param=#GET{param}}:>
    
  • Soit, spécifiquement pour ce qui est des montants, il faut appeler le formatage avec une option simplifiée dès la génération, quand on sait que c'est pour une utilisation dans une chaine de langue
    #SET{montant, #TRUC|montant_formater{#ARRAY{markup,0}}}
    <:bankouautre:whateverchaine{montant=#GET{montant}}:>
    

Mais il n'y a donc toujours que le code utilisateur parent qui peut faire des adaptations propre à son utilisation, pour que ça marche en < 4.2

Je ne sais pas d'où sort cette fake news que "ici la seule plainte concerne l'espace privé"… alors que depuis le tout début du fil ya 2 ans, ça parle "des affichages du plugin Bank" *ou n'importe quelle chaine de langue*, càd ce qu'affiche ce plugin, essentiellement aux gens aux visiteurs, donc bien dans le site, notamment dans les formulaires et boutons de paiement, donc bien dans le site. En expliquant bien que c'est parce que Bank passe en param de chaines de langue (qui ont sanitize=true par défaut), du contenu *qui peut parfaitement* contenir du HTML, et donc du HTML5 (que ce soit par Intl *ou par toute autre personnalisation de la fonction de formatage*). Autrement dit : - le HTML5 produit, peut venir de Intl OU PAS - si on parle des montants précisément, dans la fonction de formatage elle-même, il est rigoureusement impossible de discriminer pour quelle utilisation ça doit servir ensuite une fois que c'est fini d'être généré - c'est donc au code parent utilisateur qui demande le montant, de s'assurer ensuite qu'il est utilisable dans une chaine de langue (soit en désactivant le sanitize, soit en nettoyant le param avant de le passer à la chaine) La manière de contourner jusqu'à 4.1, devrait donc être de modifier les plugins qui parfois passent des choses qui peuvent contenir du HTML, en param de chaines de langue, c'est le cas de Bank mais possiblement d'autres plugins bien sûr. Pour cela trois possibilité : - Soit il faut sanitize false dans les chaines, ce qui permet de bien garder le markup ``` html [(#VAL{bankouautre:whateverchaine}|_T{ #ARRAY{montant, #GET{montant}}, #ARRAY{sanitize, ''} }|propre)] ``` - Soit il faut nettoyer le param avant, par ex ``` html #SET{param, #GET{param}|supprimer_tags} <:bankouautre:whateverchaine{param=#GET{param}}:> ``` - Soit, spécifiquement pour ce qui est des montants, il faut appeler le formatage avec une option simplifiée dès la génération, quand on sait que c'est pour une utilisation dans une chaine de langue ``` html #SET{montant, #TRUC|montant_formater{#ARRAY{markup,0}}} <:bankouautre:whateverchaine{montant=#GET{montant}}:> ``` Mais il n'y a donc toujours que le code utilisateur parent qui peut faire des adaptations propre à son utilisation, pour que ça marche en < 4.2
Owner

un ticket clair et précis donc
spip/safehtml#4790

un ticket clair et précis donc https://git.spip.net/spip/safehtml/issues/4790
Sign in to join this conversation.
No Milestone
No project
No Assignees
7 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.