Recherche avancée

Sur d’autres sites (10737)

• Revision 39914 : à priori, si on n’a pas de zones de plugins permettant de récupérer ...

  18 août 2010, par kent1@… — Log

  à priori, si on n’a pas de zones de plugins permettant de récupérer les versions à jour de plugins :
   On ne peut avoir de plugins dit "obsolètes"
   On ne peut avoir de plugins en version "supérieure" ce qui à mon avis est à peu de choses prêt que la version du dessus
  Dites moi si je me trompe…

• Evolution #3926 : Remplacement de safehtml par le plug htmlpurifier ou autre

  14 janvier 2019, par Guillaume Fahrner

  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 directement dans /prive/. A décolérer complètement à mon sens.

  Encore merci pour le temps que tu y passes :)

• Revision 39914 : à priori, si on n’a pas de zones de plugins permettant de récupérer ...

  18 août 2010, par kent1@… — Log

  à priori, si on n’a pas de zones de plugins permettant de récupérer les versions à jour de plugins :
   On ne peut avoir de plugins dit "obsolètes"
   On ne peut avoir de plugins en version "supérieure" ce qui à mon avis est à peu de choses prêt que la version du dessus
  Dites moi si je me trompe…