Project

General

Profile

Documentation #3067

Tableaux et preg_replace_callback

Added by Eric Camus almost 6 years ago. Updated almost 5 years ago.

Status:
Fermé
Priority:
Normal
Assignee:
-
Target version:
Start date:
09/30/2013
Due date:
% Done:

0%


Description

Serveur Windows avec IIS (PHP 5.2.17)

Quand la taille d'un tableau (au niveau du traitement de la fonction "protected static function replace_preg_cb" dans "engine/textwheel.php") dépasse 100Ko, l'article disparait car la fonction "preg_replace_callback" retourne "NULL".

Peut être augmenté par la variable "pcre.backtrack_limit" dans "php.ini".

Pour les autres systèmes, je ne sais pas !!!!

public_ok.png View (39.9 KB) Eric Camus, 08/27/2014 11:59 AM

prive_nok.png View (31.8 KB) Eric Camus, 08/27/2014 12:00 PM

code_source.png View (48.7 KB) Eric Camus, 08/27/2014 12:00 PM

History

#1 Updated by b b almost 6 years ago

Je ne sais pas si on peut gérer ce cas, d'autres avis à ce sujet ?

Si on ne peut le corriger dans le code, il faudra déplacer le ticket vers le tracker Documentation.

#2 Updated by guytarr ° almost 6 years ago

En utilisant preg_replace_callback ? Je ne vois pas comment mettre un correctif sur un truc qui ne renvoie pas d'erreur (voir https://bugs.php.net/bug.php?id=53825).

Modifier pour autre chose ? un spip dom parser c'est possible ?
http://stackoverflow.com/questions/4830475/preg-replace-returning-null-when-input-is-html-but-not-all-of-the-time

Je pense qu'il est plus raisonnable de déplacer en doc, 100ko pour un tableau c'est pas rien non plus.

#3 Updated by b b almost 6 years ago

  • Tracker changed from Anomalie to Documentation

#4 Updated by cedric - about 5 years ago

Il aurait été bien d'avoir un exemple concret de tableau qui fait planter la preg...

#5 Updated by Eric Camus about 5 years ago

Voici un exemple en image : la partie publique fonctionne car <100ko mais la partie privé ne fonctionne pas (ni le voir de l'édition), l'ajout des 139 "../" devant "IMG" fait alors dépasser la taille des 100ko.

Code généré par un "<img198|center>" :

<!-- class="spip_document_198" -->
 <div class='spip_images_center'>

<a href="IMG/pdf/implantation_detecteurs_incendie_2013_p1.pdf" style="text-decoration:none; background:#FFFFFF;" 
 type="application/pdf" title="Implantation des d&#039;&#233;tecteur l&#039;incendie en 2013" class=" " 
 target="_blank"  download><img src='http://10.10.10.63/imgmut/vignettes/pdf.png' height='16' width='16'
 alt='Implantation des d&#039;&#233;tecteur l&#039;incendie en 2013' class='spip_logos' /></a>

 </div>

Qui fait 507o(public), 510o(privé) et 676o(public), 680o(privé) en base 64 donc : 93964o(public), 94520o(privé) plus le reste...

Mais il me suffit d'ajouter deux "<img198|center>" de plus et la partie publique s'efface.

#6 Updated by cedric - almost 5 years ago

  • Status changed from Nouveau to Fermé
  • Target version changed from 3.0 to 3.1

Corrigé par http://zone.spip.org/trac/spip-zone/changeset/85699 : on genere une erreur squelette et le texte reste brut au lieu d'avoir un blanc

#7 Updated by Fil _ almost 5 years ago

question peut-être théorique : est-ce que ça n'ouvre pas un vecteur d'attaque en envoyant un code qui va faire exploser la mémoire et du coup passer les filtres antiscript ? si on ne sait pas garantir ça, retourner htmlspecialchars($t)

#8 Updated by cedric - almost 5 years ago

voir #2302

#9 Updated by cedric - almost 5 years ago

@Fil : bonne remarque, je me suis posé la question sur le cas ou on appelle la wheel pour interdire_scripts... J'ai failli integrer un fallback en str_replace et je me suis souvenu qu'il n'y avait pas de cas preg_xx sur cette wheel. La question est donc purement rethorique, pour le moment en tout cas.

Peut-être on devrait mettre une securite quand meme pour le cas ou ça arrive : si la wheel echappe js explose on renvoie du texte brut, c'est mieux que rien.

Also available in: Atom PDF