Recherche avancée

Sur d’autres sites (6605)

• Révision 22206 : Deux bugs dans le phraseur illustré par l’exemple ci-dessous fourni par Georges K...

  6 juin 2015, par esj -

  * (ligne 295) ce qu’il y a avant un nom de balise dans un argument n’est pas forcément du texte brut, il peut y avoir des chaînes de langues ;
  * (ligne 256) les apostrophes et guillemets en début d’argument ne sont pas forcément des délimiteurs SPIP, il faut qu’il y en ait un 2e plus loin, ce que preg_match contrôlait sans que SPIP tienne compte de son résultat. On y veille à présent mais il est à noter que cette condition est nécessaire mais non suffisante, du fait de la terrible ambiguité de la syntaxe des squelettes. Il y a donc d’autres bugs potentiels quand on met des balises comme arguments d’une balise.

  Autre chose qui ne relève pas du phraseur : dans le code ci-dessous le "**" après #SESSION n’est pas seulement destiné à produire un code plus efficace (il ne sécurise pas car ce n’est pas nécessaire quand on ne s’intéresse qu’au résultat booléen), mais aussi parce que le "interdire_script" introduit sinon transcode le chevron dans le "< ?php" de la balise dynamique #URL_LOGOUT, ce qui la neutralise. C’est un autre bug à creuser.

  <span class="CodeRay">[(#SESSION**{nom}|?{
  
  <span class="tag">&lt;:bienvenue:></span> <span class="tag"><strong></strong></span>#SESSION{nom}<span class="tag"></span>    
  
  <span class="tag">span> <span class="tag">/></span><span class="tag">span> <span class="attribute-name">href</span>=<span class="string"><span class="delimiter">'</span><span class="content">#URL_LOGOUT</span><span class="delimiter">'</span></span><span class="tag">></span><span class="tag">&lt;:logout:></span><span class="tag"></span>
  
  ,
  
  <span class="tag"><p></p></span><span class="tag"><small></small></span><span class="tag">span> <span class="attribute-name">alt</span>=<span class="string"><span class="delimiter">"</span><span class="content">&lt;:zonep:</span></span><span class="error">></span>" src="#CHEMIN{encrypted.png}" /<span class="error">></span> <span class="tag">&lt;:acces:></span> <span class="tag">span> <span class="attribute-name">href</span>=<span class="string"><span class="delimiter">"</span><span class="content">#URL_PAGE{login,url=#SELF}</span><span class="delimiter">"</span></span><span class="tag">></span><span class="tag">&lt;:ident:></span><span class="tag"></span>
  
  <span class="tag"></span><span class="tag"></span>
  
  })]
  
  </span></span></span></span></span>

• Révision 22269 : Retour sur r22264. En fait l’emplacement orginel de "interdire_scripts" provoque ...

  25 juin 2015, par esj -
  • la neutralisation inopportune des scripts introduits par le compilateur (bug corrigé par r22264) ;
    • l’altération des appels à des scripts introduits par un rédacteur, scripts q’il ne faut effectivement pas interpréter (cas du squelette nécessitant une double passe de PHP, cf. scénario possible sur http://article.gmane.org/gmane.comp.web.spip.devel/66397) mais cette stratégie brutale ne répond pas à l’intention d’un rédacteur qui s’attend à voir s’afficher le source de l’appel du script, pas le résultat de son exécution (je ne parle évidemment pas d’un rédacteur malveillant qui essaye d’exploiter une faille).

  A première vue la résolution correcte du 2e point nécessite de gros changements
  dans la stratégie de compilation adoptée depuis le début de SPIP.
  Il vaut mieux se donner le temps de la réflexion avant d’aller dans cette voie.
  Je remets le code antérieur par "svn merge -r -r22264:22263 ."
  pour ne pas laisser cette faille potentielle,
  en actant provisoirement que le premier bug doit être considéré comme une limitation de SPIP,
  savoir le fait qu’il n’est pas possible d’utiliser une balise produisant du PHP dans un argument de filtre.

• Documentation #2253 : Mettre à jour l’Aide en ligne SPIP

  3 septembre 2015, par Franck Dalot

  Bonjour :-)
  Pour ce ticket, j’ai fait pleins de copie d’écran de la version 3.1 !
  Il y a déjà eu des discussions sur ce sujet, mais je sais plus trop l’endroit (spip_dev ???)
  De mémoire, il avait été question de faire un site pour l’aide, par version de spip, mais aussi par "utilisateurs" (webmestre, admi, rédacteur, visiteur)

  Bon, perso, je suis incapable de faire un squelette complet et encore moins, la gestion d’un serveur :-( mais bon, mais je peux participer autrement.
  Je pense qu’il faut que l’on fasse plus qu’une "aide", carrément un mode d’emploi un "pas à pas" ; "aide.spip.net" ; "notice.spip.net", peu importe le nom s’il y a création d’un site, mais sans doc, spip, c’est pas simple.
  Quand je parle de mode d’emploi, c’est un site, qui traite uniquement de ce qui est "natif" (sans avoir besoin d’écrire une ligne de code)
  C’est un gros boulot au départ, mais après, cela ira plus vite pour les prochaines versions de spip.
  J’ai bien un début d’idée de comment organiser la doc, mais faut déjà savoir, qui serait partant pour enfin clore ce ticket...
  Franck