ha oui. ça va plus passer...
du moins ça ne cassera rien jusqu'à la prochaine modification
par le formulaire editer_auteur où l'enregistrement des nouvelles
données seront bloquées sur la signature.
:-/
* denisb tapuscrivait, le 16/11/2013 01:18:
Avec les enluminures typo, j'ai souvent mis ou fait mettre des petites
capitales sur le nom propre : Jean <sc>Martin</sc>ha oui. ça va plus passer...
du moins ça ne cassera rien jusqu'à la prochaine modification
par le formulaire editer_auteur où l'enregistrement des nouvelles
données seront bloquées sur la signature.:-/
Si au moins
function nom_acceptable($nom) {
était
function nom_acceptable_dist($nom) {
Ce serait surchargeable une fois.
Idéalement, il faudrait que "multi" soit dans une globale*
La globale séparant les éléments autorisés par une virgule ','
Et la fonction ferait un explode sur la virgule pour créer le tableau des rechercher/remplacer.
* j'ai pensé à un define, mais ça ne serait surchargeable qu'une fois aussi.
Pour des questions éditoriales/de mise en forme on peut aussi vouloir mettre un <i> ou un <b>.
On ne pourrait pas laisser passer tous les tags simples sans attributs, avec une regexp ?
Genre on bloque si
preg_match(",</?\w+[\s=][^>]*>,",$nom)
Est-ce que ça laisserait une possibilité d'attaque ?
Cédric
<script>alert('boum');</script>
Mais heu !
D'abord les scripts sont bloqués dans l'espace privé, et visibles, donc ça fait quand même échouer le scenario ou l'auteur essayait de hacker un admin non ?
Bon alors plus secure :
- on bloque si des balises non simples (avec attribut)
- on bloque si safehtml() modifie le contenu
Ça irait comme compromis ?
Cédric
Mais heu !
D'abord les scripts sont bloqués dans l'espace privé, et visibles, donc ça fait quand même échouer le scenario ou l'auteur essayait de hacker un admin non ?
1) display:none dans le privé pour masquer le script sur le nom
2) cas d'un site qui affiche dans le public la liste des visiteurs
inscrits.
dans ce cas là (c'est un exemple) il suffit en étant loggué de
visualiser la page où s'affiche cette liste d'inscrits pour lancer
un xss.
- on bloque si des balises non simples (avec attribut)
oui
- on bloque si safehtml() modifie le contenu
moué bof : <h1>, <hr>, <form>, <input>, ...
évitons des "<textarea>salut lulu</textarea>" et autres "<input>" dans
la signature, mais autorisons ce que le webmestre a décidé
d'autoriser :
function nom_acceptable($nom) {
if (!is_string($nom)) {
return false;
}
if (!defined('_TAGS_LOGIN')) define('_TAGS_LOGIN','');
$tags_acceptes = array_unique(explode(',', 'multi,' . _TAGS_LOGIN));
foreach($tags_acceptes as $tag) {
if (strlen($tag)) {
$remp1[] = '<'.trim($tag).'>';
$remp1[] = '</'.trim($tag).'>';
$remp2[] = '\x60'.trim($tag).'\x61';
$remp2[] = '\x60/'.trim($tag).'\x61';
}
}
$v_nom = str_replace($remp2, $remp1, supprimer_tags(str_replace($remp1, $remp2, $nom)));
return str_replace('<', '<', $v_nom) == $nom;
}
il devient possible de définir dans mes_options.php
ou dans un plugin_options.php :
defined('_TAGS_LOGIN') || define('_TAGS_LOGIN', 'b, i,abbr, truc');
on est volontairement laxiste sur l'écriture de la constante :
avec ou sans espaces, déclaration vide, double déclaration...
par défaut "multi" sera toujours accepté.
\x60 et \x61 sont, je pense, acceptables :
pour que ça pouiche, il faudrait que l'auteur intègre "\x60b\x61"
à sa signature *et* que "b" soit dans la constante (ça devrait limiter
les collisions...)
* denisb tapuscrivait, le 21/11/2013 12:05:
- on bloque si des balises non simples (avec attribut)
- on bloque si safehtml() modifie le contenuévitons des "<textarea>salut lulu</textarea>" et autres "<input>" dans
la signature, mais autorisons ce que le webmestre a décidé
d'autoriser :function nom_acceptable($nom) {
if (!is_string($nom)) {
return false;
}
if (!defined('_TAGS_LOGIN')) define('_TAGS_LOGIN','');
$tags_acceptes = array_unique(explode(',', 'multi,' . _TAGS_LOGIN));
foreach($tags_acceptes as $tag) {
if (strlen($tag)) {
$remp1 = '<'.trim($tag).'>';
$remp1 = '</'.trim($tag).'>';
$remp2 = '\x60'.trim($tag).'\x61';
$remp2 = '\x60/'.trim($tag).'\x61';
}
}
$v_nom = str_replace($remp2, $remp1,
supprimer_tags(str_replace($remp1, $remp2, $nom)));
return str_replace('<', '<', $v_nom) == $nom;
}il devient possible de définir dans mes_options.php
ou dans un plugin_options.php :
defined('_TAGS_LOGIN') || define('_TAGS_LOGIN', 'b, i,abbr, truc');on est volontairement laxiste sur l'écriture de la constante :
avec ou sans espaces, déclaration vide, double déclaration...par défaut "multi" sera toujours accepté.
\x60 et \x61 sont, je pense, acceptables :
pour que ça pouiche, il faudrait que l'auteur intègre "\x60b\x61"
à sa signature *et* que "b" soit dans la constante (ça devrait limiter
les collisions...)
Ça parait effectivement plus intéressant.
En en discutant sur IRC, nous avons noté que ça permettait aussi de gérer 'br /'.
Mais pas <img12|center>
Il faudra bien dire dans l'annonce qu'il peut y avoir rupture de compatibilité à l'enregistrement/création.
Merci à toi d'avoir cherché à rendre ça un minimum paramétrable !
ça a l'air bien ça... A méditer encore ou gogogo pour next version ?
* denisb tapuscrivait, le 21/11/2013 12:05:
il devient possible de définir dans mes_options.php
ou dans un plugin_options.php :
defined('_TAGS_LOGIN') || define('_TAGS_LOGIN', 'b, i,abbr, truc');
Intégré dans les ETv3 afin d'anticiper :
Merci
Intégré dans les ETv3 afin d'anticiper :
typo (gros doigts ?) :
>typoenluminee_options.php</options>
....^
(enluminures_typographiques_v3/plugin.xml L26)
Non mais aaaaah. Mais j'ai encore laissé passé un problème de nommage comme ça moi, malgré ma lecture assidue. Je suis désolé, mon énervement suivant est aussi contre moi-même.
Franchement les gars (ouais, j'ai pas encore eu de récrimination de nommage fait par une fille pour l'instant, ici), c'est si compliqué que ça d'appeler un chat : "UN CHAT" ? Pourquoi est-ce que vous préférez toujours appeler un chat : "UNE BELETTE" ?
On parle d'une variable de configuration qui s'applique au champ "nom" d'un auteur, et on l'appelle "LOGIN" qui est un autre champ. Non mais WTF.
Et SPIP est *truffé* de nommages de ce genre partout.
On doit déjà se coltiner l'historique (des fois des trucs au singulier, des fois au pluriel, sans cohérence, etc) + les fonctions PHP qui n'ont jamais la même norme de nommage ou d'ordre des arguments, mais on s'amuse *en plus* dans les nouveaux développements, à ajouter des noms qui n'ont pas de rapport avec ce que ça fait.
Et c'est d'autant plus important pour les variables (les constantes de conf notamment) ou fonctions (les filtres par ex) qui sont destinées à être directement utilisées par les gens non-dev (les gens qui configurent leur site ou qui codent des squelettes).
Un jour on fera un comité de nommage, et tout nouvel ajout destiné à être public (API ou constante) sera passé au crible de la question : "est-ce vraiment le nom le plus approprié ?"
Pfff.
Donc on renomme _TAGS_NOM_AUTEURS ?
Ah ben moi aussi je poste trop vite...
C'est une proposition non encore commitée qui vise à rendre de la
souplesse sur un patch un peu sec...
Donc bon, sous réserve du renommage, que je trouve intelligent, je reste
pour 
Et :-*
On peut aussi l'appeler "Minou"... 
Bon, je sors.
C'est une proposition non encore commitée qui vise à rendre de la
souplesse sur un patch un peu sec...
Au temps pour moi, commité il y a 7 jours non encore publié dans une
version SPIP. Du coup, je maintiens ce qui suit.
Donc bon, sous réserve du renommage, que je trouve intelligent, je reste
pour
Et je veux bien faire si gogogo (c'est dans mes cordes).
$ svn commit -m "un chat n'est pas une belette !" /branches/spip-3.0/ecrire/inc/filtres.php
Il existe : c'est la nomenklatura.
Ce comité est autosaisi par qui éprouve le besoin irrépressible de nommage plus pertinents, significatifs, logiques, simples et agréables, comme tu viens de le faire.
cf http://contrib.spip.net/Nomenklatura
JL
Un jour on fera un comité de nommage, et tout nouvel ajout destiné à être public (API ou constante) sera passé au crible
de la question : "est-ce vraiment le nom le plus approprié ?"
Oui, ce manque est une des raisons pour lesquelles le code de SPIP est devenu illisible.
Pour Langonet, Eric a défini des règles de nommage qui me semblent un bon début
je serai encore plus restrictif en disant qu'un nom de fonction doit commencer par un verbe,
et que ce verbe indique implicitement le type de résultat de la fonction, information cruellement manquante en PHP
(par exemple une fonction commençant par "compter_" retourne toujours un entier etc).
Il existe : c'est la nomenklatura.
Ce comité est autosaisi par qui éprouve le besoin irrépressible de nommage plus pertinents, significatifs, logiques, simples et agréables, comme tu viens de le faire.
cf Nomenklatura
Je viens d'y faire un ajout.
Committo,Ergo:Sum