Sur un site (ici: Le Carré des canotiers) le formulaire en bas de page ne se charge plus et ça a l’air concomitant avec toutes les mises à jour de ces derniers temps … J’ai testé PHP7 et 8, idem, ce sont des formulaires faits à la main, ils marchaient encore récemment … J’ai ça qui s’affiche à la place:
En erreur PHP j’ai un petit warning sur html5up_phantom mais rien qui semble bloquant.
Si j’ajoute ce qu’il faut pour afficher les erreurs je n’ai rien de plus que ce qui précède. Ce genre d’erreur peut venir que quoi, si quelqu’un a une piste je suis intéressé
Pierre
PS: une précision: si je commente absolument tout le code dans le fichier php du formulaire j’ai la même erreur, donc on ne dirait pas que c’est un souci dans le formulaire lui-même mais plustot dans son appel … et comme je l’ai dit ces formulaires fonctionnent depuis au moins 3 ans.
PS2: et zut, il faut creer un compte de contributeur pour voir cette page …
PS3: et je trouve bizarre le if ($lang_select = "fr") dans cette erreur … ça vient de Spip non ? ne devrait-on pas avoir if ($lang_select == "fr") ?
Qui est dans un inclure/contribforms.html lui-même appelé depuis rubrique.html … ce formulaire a bien sûr un formulaires/editer_accastillage.php et html …
Et tout ça fonctionne depuis plusieurs années.
Ben oui ça semble solutionner le problème !! C’est les récentes mises à jour qui ont généré ce problème ?
Merci en tous cas, je propage aux 3 formulaires qui sont sur le même modèle. Je ne marque pas encore comme résolu dans l’attente d’un retour de @maieul et pour voir s’il faut ouvrir un ticket de bug mais grand merci !!
Pour faire court, spip applique le filtre de sécurité à sa balise UNE fois les filtres passés. Et comme on est plus severe sur la sécu dans les toutes dernières versions, bah ca a pété avec la syntaxe [(#ID|?{...})].
Avec |oui) tu met ton formulaire non pas comme argument d’un filtre mais comme partie optionelle d’une balise… et donc ca marche normalement à tout les coup.
Je pense qu’en SPIP 4.4 on va être obligé de revenir en arrière et de se contenter d’un spip_sanitize_from_request() sur les balises XXX qui viennent du env (et donc avoir quelque chose différent de #ENV{xxx} parce que ça pète trop de choses et je vois pas comment faire autrement, vu qu’on est sur des releases mineures.
Par contre en SPIP 5 on va garder ce qu’on a fait et il y aura rupture de compat là dessus, obligeant à écrire l’expression autrement, soit avec un [(#ID*|?{...})] soit avec un [(#ID|oui) ...)]
Il me semble qu’il y a de toute facon un problème de fond : pourquoi est-ce que les fonctions de sécurité doivent-elles s’appliquer aux balise UNE FOIS LES FILTRES PASSÉS et pas aux balise AVANT LE PASSAGE DES FILTRES ?
Peut-être parce que c’est le résultat final qui peut-être dangereux et qu’on veut sécuriser ?
Suppose que tu affiches un truc comme
[(#TOTO|replace{'.',''})]
Et que tu appliques interdire_scripts sur le contenu de #TOTO avant les filtres : il suffit d’injecter <.s.c.r.i.p.t.>alert('paf le chien');<./.s.c.r.i.p.t> pour passer à travers interdire_scripts et produire du contenu dangereux après passage du filtre
Même si c’est pénible tu as pas d’autres choix que de sécuriser par défaut le texte produit final et non la seule valeur d’entrée des filtres.
