le critère {agenda} (www.spip.net/fr_article3182.html) a besoin que ses
deux premiers arguments soient, je cite, "littéraux (autrement dit ils
ne peuvent être calculés dynamiquement par #ENV ou toute autre balise)."
ça signifie par exemple qu'il n'est pas possible de faire
pour pouvoir utiliser la même boucle pour filtrer, selon un paramètre
type_date, sur le champ "date", "date_redac" ou "maj". On est obligé de
choisir sur quel champ faire le filtre, par exemple
Est-ce possible d'inclure cette fonctionnalité manquante ?
Le diff suivant, appliqué sur le fichier ecrire/public/critere.php,
permet d'utiliser des balises (#GET, #ENV, etc.) pour le premier
argument : http://spip.pastebin.fr/31769
le critère {agenda} (www.spip.net/fr_article3182.html) a besoin que ses
deux premiers arguments soient, je cite, "littéraux (autrement dit ils
ne peuvent être calculés dynamiquement par #ENV ou toute autre balise)."
...
Est-ce possible d'inclure cette fonctionnalité manquante ?
Le diff suivant, appliqué sur le fichier ecrire/public/critere.php,
permet d'utiliser des balises (#GET, #ENV, etc.) pour le premier
argument : http://spip.pastebin.fr/31769
Le pb n'est pas dans l'analyse syntaxique, qui se résoud comme tu a écrit,
mais dans le fait que si le résultat de #ENV est n'importe quoi,
cela va produire un requête SQL fautive voire dangereuse.
Implémenté dans mediaspip_core, en limitant aux seules valeurs 'date',
'date_redac' et 'maj' : http://zone.spip.org/trac/spip-zone/changeset/78701/squelettes/mediaspip/mediaspip_core/trunk/mediaspip_core_fonctions.php
Hmmm, ça suffit pour que la requête SQL soit protégée des injections, mais elle peut toujours etre fautive si la table concernée n'a pas les champs que tu listes,
et a contrario si elle en a d'autres acceptables, tu les refuseras.
Mais pour être honnête il faut reconnaître que le code actuel n'est pas très robuste non plus sur ce point, même si c'est moins grave puisque c'est forcément le squelette qui est faux, psa son usage.
Je viens d'envoyer une modif qui d'une part blinde le cas du litteral en testant s'il est dans la table concerné, et qui accepte finalement un argument calculé en vérifiant dynamiquement que le résultat est bien un champ de la table. Je pense que ça résoud tous les manques:
Super, merci pour les améliorations et le commit !
Mediaspip étant basé sur spip 3, je vais laisser la surcharge dans le
plugin et adapter le code pour régler ces soucis. Si le code est versé
dans spip 3 aussi, je me demande comment gérer la présence du correctif
à la fois dans ecrire/ et dans le plugin, pas sûr qu'on puisse les chaîner.