J'ai mis en place la pagination dans mon squelette.
Merci James et Fil, ça faisait longtemps que j'attendais çà.
Tout ce que j'ai noté c'est que si la boucle xxx est inclue, il faut {debut_xxx} avec l'INCLURE, pour la transmission du paramètre debut_xxx=50
Tout ce que j'ai noté c'est que si la boucle xxx est inclue, il faut
{debut_xxx} avec l'INCLURE, pour la transmission du paramètre debut_xxx=50
Je crois que ça ne suffit pas, et qu'il faut en fait passer tout l'url avec
{self=#SELF} pour éviter tout XSS
-- Fil
Fil a écrit :
Tout ce que j'ai noté c'est que si la boucle xxx est inclue, il faut {debut_xxx} avec l'INCLURE, pour la transmission du paramètre debut_xxx=50
Je crois que ça ne suffit pas, et qu'il faut en fait passer tout l'url avec
{self=#SELF} pour éviter tout XSS
Chez moi #SELF référencerait la page d'appel et non la page appelée.
> Je crois que ça ne suffit pas, et qu'il faut en fait passer tout l'url avec
> {self=#SELF} pour éviter tout XSSChez moi #SELF référencerait la page d'appel et non la page appelée.
Oui je sais bien, mais ça permet de faire que le cache (du squelette inclus)
soit fonction de l'ensemble de l'URL (d'appel). Cela dit je crois qu'on
utilise maintenant _request() pour aller chercher la valeur de debut_xxxx,
ça doit supprimer le risque de XSS (qui est là quand on utilise $GLOBALS,
car il suffit alors que je mette un cookie debut_xxx dans mon navigateur
pour "forcer" ta page à se paginer sur un nombre autre que 0).
-- Fil
Fil a écrit :
Je crois que ça ne suffit pas, et qu'il faut en fait passer tout l'url avec
{self=#SELF} pour éviter tout XSSChez moi #SELF référencerait la page d'appel et non la page appelée.
Oui je sais bien, mais ça permet de faire que le cache (du squelette inclus)
soit fonction de l'ensemble de l'URL (d'appel).
C'est juste, il faut donc une balise similaire à #SELF, disons #PAGE. Et pour l'appel ce serait {self=#PAGE} ?
Cela dit je crois qu'on
utilise maintenant _request() pour aller chercher la valeur de debut_xxxx,
ça doit supprimer le risque de XSS (qui est là quand on utilise $GLOBALS,
car il suffit alors que je mette un cookie debut_xxx dans mon navigateur
pour "forcer" ta page à se paginer sur un nombre autre que 0).
_request() ?
> Oui je sais bien, mais ça permet de faire que le cache (du squelette inclus)
> soit fonction de l'ensemble de l'URL (d'appel).C'est juste, il faut donc une balise similaire à #SELF, disons #PAGE. Et
pour l'appel ce serait {self=#PAGE} ?
Je ne comprends pas ce que tu veux dire. Mais à la réflexion {debut_xxx}
suffit probablement.
> Cela dit je crois qu'on
> utilise maintenant _request() pour aller chercher la valeur de debut_xxxx,
> ça doit supprimer le risque de XSS (qui est là quand on utilise $GLOBALS,
> car il suffit alors que je mette un cookie debut_xxx dans mon navigateur
> pour "forcer" ta page à se paginer sur un nombre autre que 0)._request() ?
C'est une fonction interne de spip qui donne soit $_GET soit $_POST (mais
pas $_COOKIE ni $_SERVER)
-- Fil
Fil a écrit :
Oui je sais bien, mais ça permet de faire que le cache (du squelette inclus)
soit fonction de l'ensemble de l'URL (d'appel).C'est juste, il faut donc une balise similaire à #SELF, disons #PAGE. Et pour l'appel ce serait {self=#PAGE} ?
Je ne comprends pas ce que tu veux dire. Mais à la réflexion {debut_xxx}
suffit probablement.
C'est pas clair mon truc. je reprends :
#PAGE{toto} c'est comme #SELF sauf que le fond est fixé à toto. Ma question était de savoir quelle serait la syntaxe pour faire INCLURE avec #PAGE{toto}
>> C'est juste, il faut donc une balise similaire à #SELF, disons #PAGE. Et
>> pour l'appel ce serait {self=#PAGE} ?
Ah ça y est j'ai retrouvé la raison profonde du truc : regarde sur la
petition (article.html,
<INCLURE{fond=inc-petition}{id_article}{self=#SELF}>).
Ce qui se passe c'est que cet INCLURE va créer un cache qui sera servi à
toutes les pages qui l'appelleront avec les mêmes arguments.
Si on ne met que {id_article}, on perd la pagination : pire, si quelqu'un
"calcule" le cache avec un debut_signatures=20, le visiteur suivant se
retrouve avec les signatures paginées à partir de 20.
Si on met {id_article}{debut_signatures}, le problème précédent disparaît ;
en revanche le cache de la pétition est calculé avec les liens de pagination
basés sur #SELF.
Suppose maintenant que le cache du site est vide ; je suis un attaquant et
j'appelle ?article1&ta_mere=en-short ; le cache du fragment inclus sera donc
calculé avec cette vilaine URL comme "self", et les liens de pagination
seront ?article1&ta_mere=en-short&debut_signatures=20 etc
Maintenant le visiteur suivant sur la page ?article1 se verra servir *ce
même cache*, et donc verra ta_mere=en-short dans les URLs de pagination.
Le seul moyen actuel pour éviter cette "attaque", c'est de fonder l'url de
cache du fragment sur l'url de la page, donc de mettre {xxxxx=#SELF} dans la
balise INCLURE.
Une autre (meilleure) méthode serait de faire une inclusion "inline",
c'est-à-dire qui stockerait le fragment dans le cache de la page principale.
Mais ça n'existe pas encore dans SPIP. Mon idée c'est que les
INCLURE{fond=xxx} devraient être "inline", tandis que les INCLURE(xxx.php)
seraient comme maintenant. Mais c'est post-1.9 
-- Fil
Salut,
Fil a écrit :
(...)
Une autre (meilleure) méthode serait de faire une inclusion "inline",
c'est-à-dire qui stockerait le fragment dans le cache de la page principale.
Mais ça n'existe pas encore dans SPIP. Mon idée c'est que les
INCLURE{fond=xxx} devraient être "inline", tandis que les INCLURE(xxx.php)
seraient comme maintenant. Mais c'est post-1.9
juste une reflexion "fonctionnelle" la dessus car j'use et j'abuse de l'inclusion depuis un moment maintenant.
J'utilise sur mes developpements (1.8) plusieurs scripts pour les inclusions.
J'ai une version de page.php3 à la racine et une autre dans /squelette
La premiere est le controleur(point d'acces unique), la seconde n'est pas accessible directement et peut s'appuyer sur des informations fournies par le controleur (autorisation, variables d'environnement, chemin des squelettes ...)
Mais la seconde (bloc.php3 chez moi) est declinée en plusieurs versions selon les usages.
J'ai donc aussi un bloc_perso.php3 qui ajoute l'id de l'utilisateur au contexte, un bloc_statut, et au besoin, un bloc_xxx correspondant à une variable xxx d'environnement définie au niveau du controleur.
Mais les fameux blocs inclus (noisettes ou autre gadgets) manquent finalement d'autonomie et j'ai tendance rapidement à faire des formulaires.
On maitrise parfaitement le contexte en passant les parametres un par un en mais c'est loin d'etre top au niveau de la maintenance
On perd beaucoup de l'interet des inclusions puisque l'ajout d'un parametre (genre pagination) va declencher des modifs en cascade.
Normal dans un sens puisqu'on change "l'interface" ... mais si on regarde le cas de la pagination, on se dit qu'il serait plus simple de pouvoir definir au niveau du squelette des variables d'environnement à aller chercher systematiquement
Je ne sais pas si c'est réalisable, mais il y a, amha, deux types de variables dans le contexte :
- celles definies par le contexte appelant (comme actuellement <INCLURE{xxx}>)
- celles definies par le fichier appelé (ce qui manque amha)
et dans les 2 cas, 2 contextes distincts :
- le contexte d'appel (get, post, variables d'environnement comme statut, id de l'auteur, url appelée ...) : on le fait aujourd'hui avec {xxx=#ENV{xxx}} mais l'environement est aujourd'hui le contexte d'execution ou, via #ENV, le contexte parent, qui peut etre different du contexte d'appel
- le contexte d'execution, ce qu'on fait aujourd'hui : {xxx} ou {xxx=#_boucle:BALISE}
Faire la distinction entre #ENV{xxx} et le variable xxx passée en GET ou POST ne me parait pas indispensable, mais quand on commence à avoir un peu de profondeur d'inclusions, ca simplifierait bien la vie de pouvoir mettre #REQUEST{xxx} sans avoir à passer xxx à tous les etages.
Pouvoir definir des variables au niveau du squelette, je ne sais pas comment ca peut se faire, mais je vois bien l'interet !
Quand on fait un squelette de menu ou un petit bloc d'affichage de breve, on le fait pour etre appelé dans un certain contexte.
Le plus important est en l'accès au contexte d'appel, ce qui est sans doute le plus simple à implanter.
Mais pouvoir definir dans le squette une "collecte" serait pas mal non plus.
Ca n'empeche pas de vouloir parfois passer d'autres parametres et il est evident que le contexte appelant prime, mais ca serait un vrai gain en maintenabilité et en portabilité des developpements.
mes 2 sous ...
@++
PS : bon, je me suis pas laché, j'ai pas parler de la definition intelligente du contexte...
Fil wrote:
Le seul moyen actuel pour éviter cette "attaque", c'est de fonder l'url de
cache du fragment sur l'url de la page, donc de mettre {xxxxx=#SELF} dans la
balise INCLURE.
Malgré ces belles explications détaillées, je n'ai pas compris :
dans quel cas en général faut il pour raison de sécurité
ajouter {self=#SELF} aux critères d'un INCLURE ??
JLuc
> Le seul moyen actuel pour éviter cette "attaque", c'est de fonder l'url de
> cache du fragment sur l'url de la page, donc de mettre {xxxxx=#SELF} dans la
> balise INCLURE.Malgré ces belles explications détaillées, je n'ai pas compris :
dans quel cas en général faut il pour raison de sécurité
ajouter {self=#SELF} aux critères d'un INCLURE ??
Dans le cas où ton squelette inclus contient la balise #SELF ou #PAGINATION
(car cette dernière fait appel à #SELF). Et c'est tout.
-- Fil
Fil wrote:
Le seul moyen actuel pour éviter cette "attaque", c'est de fonder l'url de
cache du fragment sur l'url de la page, donc de mettre {xxxxx=#SELF} dans la
balise INCLURE.Malgré ces belles explications détaillées, je n'ai pas compris :
dans quel cas en général faut il pour raison de sécurité
ajouter {self=#SELF} aux critères d'un INCLURE ??Dans le cas où ton squelette inclus contient la balise #SELF ou #PAGINATION
(car cette dernière fait appel à #SELF). Et c'est tout.
ok j'ai compris et comme ça attire mon attention sur quelquechose
auquel je n'ai jamais pensé, je l'ai reporté
sur http://www.spip-contrib.net/spikini/PagePrincipale?wiki=ConseilsSecurite
Peut être il y en a d'autres comme ça ?
JL
* Stephane LAURENT tapotait, le 06/06/2006 00:16:
Salut,
Pouvoir definir des variables au niveau du squelette, je ne sais pas comment ca peut se faire, mais je vois bien l'interet !
Une solution : Déclarer des variables dans SPIP 1.9 - Pyrat.net – Création de sites Internet
une autre 
http://trac.rezo.net/trac/spip-zone/browser/plugins/boucles/Boucles_sans_tables/boucleTableau.php?rev=3238
Jacques PYRAT a écrit :
* Stephane LAURENT tapotait, le 06/06/2006 00:16:
Salut,
Pouvoir definir des variables au niveau du squelette, je ne sais pas comment ca peut se faire, mais je vois bien l'interet !
Une solution : Déclarer des variables dans SPIP 1.9 - Pyrat.net – Création de sites Internet
enfin la par rapport a ce qu'expliquait stephane ca apporte pas grand chose.
Le probleme sous-jacent, c'est que quand tu fais un inclure dans lequel tu passes une variable de contexte, la gestion du cache prend en compte cette variable. Deux valeurs differentes vont generer deux pages de cache differentes.
Si on by-pass ca en creant un #REQUEST alors ca devient plus compliqué.
Cela suppose du coup une analyse du squelette pour faire remonter les dependances. C'est possible lors de la compilation, mais apres, au moment de l'execution ca ne le devient plus car tout ce qu'on connait avant de voir si une page est en cache c'est son contexte appelant.
Si il faut reanalyser le squelette pour redefinir le cache effectif compte tenu des dependances les performances vont s'ecrouler.
Par ailleurs, du point de vue développement, le passage des variables en argument du inclure me parait une demarche assez saine, analogue au passage des variables dans les appels de fonction dans du code.
Cedric
cedric.morin@yterium.com a écrit :
Jacques PYRAT a écrit :
* Stephane LAURENT tapotait, le 06/06/2006 00:16:
Salut,
Pouvoir definir des variables au niveau du squelette, je ne sais pas comment ca peut se faire, mais je vois bien l'interet !
Une solution : Déclarer des variables dans SPIP 1.9 - Pyrat.net – Création de sites Internet
enfin la par rapport a ce qu'expliquait stephane ca apporte pas grand chose.
oui, en fait, je parle juste des difficultés à faire des inclures autonomes, surtout quand on a 3 ou 4 niveaux d'inclusion ...
je sais bien que ca n'est pas l'usage courant, mais je fais généralement une première passe qui va definir les squelettes, css et gère la sécurité ...
et derrière, j'ai une couche qui positionne les différents éléments inclus.
Si ces éléments sont complexes, ils nécessitent eux même plusieurs inclures ...
Le probleme sous-jacent, c'est que quand tu fais un inclure dans lequel tu passes une variable de contexte, la gestion du cache prend en compte cette variable. Deux valeurs differentes vont generer deux pages de cache differentes.
oui, en plus, mais c'est surtout la maintenabilité qui m'embete.
si la variable utilisée bouge trop sur une navigation de toutes facons, il vaut mieux faire un script d'inclusion specifique qui place directement la variable dans le contexte.
Si on by-pass ca en creant un #REQUEST alors ca devient plus compliqué.
non, je ne pense pas que maintenir en plus de #ENV un "singleton" #REQUEST, alimenté à l'appel principal, pose probleme et ca serait deja un grand confort (heu, il suffit peut etre de faire une balise qui pioche dans $_REQUEST ... non ?).
C'est plutot la definition des variables necessaires DANS le squelette qui pose probleme, mais qui serait vraiment top, chaque "noisette" collectant elle meme son contexte.
On peut faire l'equivalent avec les formulaires, mais on ajoute forcement un peu de traitement à chaque appel.
C'est dommage, sans aller dans des grandes analyses syntaxiques, le compilo doit pouvoir le gerer si la syntaxe est strticte (genre <COLLECTER()> situé obligatoirement au debut du squelette)
Cela suppose du coup une analyse du squelette pour faire remonter les dependances. C'est possible lors de la compilation, mais apres, au moment de l'execution ca ne le devient plus car tout ce qu'on connait avant de voir si une page est en cache c'est son contexte appelant.
Si il faut reanalyser le squelette pour redefinir le cache effectif compte tenu des dependances les performances vont s'ecrouler.Par ailleurs, du point de vue développement, le passage des variables en argument du inclure me parait une demarche assez saine, analogue au passage des variables dans les appels de fonction dans du code.
c'est sain pour un developpeur mais pour les autres ?
Aujourd'hui, si tu fais une contrib avec un petit squelette à inclure (noisette), il faut penser à lui faire ses variables pour l'utiliser dans un inclure,c'est dommage.
Passer les variables issues du contexte d'execution me parait sain (mais essayer à defaut de parametre de chercher le chercher tout seul est un plus)
Mais pour toutes les variables issues du contexte d'appel (REQUEST), ca me parait moins evident, et surtout pas super pratique.
Mais bon, c'etait juste 2 sous en reaction à ce que disait Fil ... je ne connais pas assez cette partie du code pour savoir si et comment c'est faisable
@++
JLuc wrote:
ok ... ça attire mon attention sur quelquechose
auquel je n'ai jamais pensé, je l'ai reporté
sur http://www.spip-contrib.net/spikini/PagePrincipale?wiki=ConseilsSecuritePeut être il y en a d'autres comme ça ?
c'est pas directement lié à spip mais ça concerne tous les sites spip !
Si les connaisseurs mettaient en forme la substantifique moelle
de leur expérience de la sécurité alliée à spip,
ce serait un grand plus ...
Merci à vous qui le pouvez de contribuer à la page ci dessus !
JLuc
j'ai rien compris 
christian lefebvre wrote:
sur http://www.spip-contrib.net/spikini/PagePrincipale?wiki=ConseilsSecurite
j'ai rien compris
Oui. Ya du boulot pour rendre les bases techniques de la sécurisation
d'un site compréhensibles et plus accessibles.
Le premier titre est trop "magique" : il faudrait bien expliquer les raisons qui y mènent
et le 2eme est trop "abstrait" : à ces principes il faudrait ajouter un guide ou un exemple d'application.
Je suis novice et n'ai mis là ce que j'ai chopé qui m'a semblé utile.
j'espère que des connaisseux pourront ajouter les éléments manquant utiles
et que ça pourra dresser un portrait suffisant des éléments pour la sécurité d'un site spip.
JLuc
j'ai mis le code correspondant à mon explication sur ta page du wiki.
Je precise que la méthode n'est pas de moi, c'est repiquée sur le bloog de Booz.
J'en avais fait aussi une version avec la securité au niveau des articles egalement, mais c'etait lourd et peu utilisé, une autre avec les extras, plus de traitement mais pas de problemes de "mots techniques" à exclure des boucles mots.
Mais aujourd'hui, je prefere aborder la securité comme de la "personnalisation" (cad qu'on fait un cache par personne, mais au niveau des "noisettes".
Et les formulaires offrent finalement beaucoup de possibilité sans trop degrader les perfs (un peu quand meme ...)
à voir sur spip_zone :
_contribs_\_formulaires_\modifier_article
et
_contribs_\_formulaires_\documents
avec pour tester un squelette article :
<BOUCLE_article_principal(ARTICLES){id_article}>
[<div style="float:right;">(#FORMULAIRE_BOUTON_MODIFIER_ARTICLE)</div>]
<div style="float:right; clear:right;width:250px;">
[(#FORMULAIRE_AJOUTER_DOCUMENT_ARTICLE)]
</div>
[(#FORMULAIRE_MODIFIER_ARTICLE)]
[(#FORMULAIRE_DOCUMENTS_ARTICLE)]
</BOUCLE_article_principal>
c'est un premier jet, mais ca rend deja bien le service ...
Je developpe ca dans le cadre de mon tetraspip v1.1 qui permet de restreindre les auteurs et les visiteurs à certaines rubriques.
On peut comme ca faire des groupes de travail restreints ou tout est produit depuis le site public.
L'utilisateur sans droit voit uniquement ce qui est publié.
Retours bienvenus ...
@++
PS : c'est pour la 1.8.3 ...
JLuc a écrit :
