[spip-dev] alea_ancien ne sert plus à rien

Dev
1

Bonjour,

Auparavant SPIP gérait proprement le cas où, ayant donné un clé d'action avec un aléa à l'instant T,
l'utilisateur demande l'action à l'instant T+x où l'aléa a changé: SPIP garde dans sa BD la valeur de l'ancien alea, et accepte de comparer la clé aux 2 valeurs possibles fournies par les 2 aleas.

Sauf que maintenant les actions ont souvent une URL qui n'est pas à la racine de SPIP, mais descend au niveau /ecrire, ce qui provoque une authentification avant le déclenchement de l'action. Comme les procédures de vérif d'authentification ne tiennent pas compte de l'ancien alea, l'action est refusée et on est redirigé sur le formulaire de login, avec un faux message disant qu'il y a un pb avec le cookie. On peut bien saisir le mot de passe, la redirection a fait que le flux d'entrée (i.e. les saisies du formulaire) est perdu.

Je ne compte plus le nombre de bugs que ce laxisme concernant les URLs des actions a introduits.
Je le répète: ce changement est un ajour d'indétermination dans le contexte, et ce genre d'opération ne peut conduire qu'à cette situation de bugs en rafale. Je ne comprends toujours pas ce qu'on gagne en echange, et je redis qu'ils faut abandonner ce truc là.

Emmanuel

2

Committo,Ergo:sum a écrit :

Je ne compte plus le nombre de bugs que ce laxisme concernant les URLs des actions a introduits.
Je le répète: ce changement est un ajour d'indétermination dans le contexte, et ce genre d'opération ne peut conduire qu'à cette situation de bugs en rafale. Je ne comprends toujours pas ce qu'on gagne en echange, et je redis qu'ils faut abandonner ce truc là.

Bonjour,

je confirme et donc je partage !

Roger Burton

3

Bonjour,

Auparavant SPIP gérait proprement le cas où, ayant donné un clé d'action avec un aléa à l'instant T,
l'utilisateur demande l'action à l'instant T+x où l'aléa a changé: SPIP garde dans sa BD la valeur de l'ancien alea, et accepte de comparer la clé aux 2 valeurs possibles fournies par les 2 aleas.

Sauf que maintenant les actions ont souvent une URL qui n'est pas à la racine de SPIP, mais descend au niveau /ecrire, ce qui provoque une authentification avant le déclenchement de l'action. Comme les procédures de vérif d'authentification ne tiennent pas compte de l'ancien alea, l'action est refusée et on est redirigé sur le formulaire de login, avec un faux message disant qu'il y a un pb avec le cookie. On peut bien saisir le mot de passe, la redirection a fait que le flux d'entrée (i.e. les saisies du formulaire) est perdu.

Je ne compte plus le nombre de bugs que ce laxisme concernant les URLs des actions a introduits.

Le laxisme n'est il pas plutôt qu'on accepte de faire une opération de modification en base de donnée sans être identifié ?

Je le répète: ce changement est un ajour d'indétermination dans le contexte,

Au contraire, puisque l'action sait maintenant dans quel contexte elle s'execute (espace privé ou espace public). Le processus est à ce titre bien plus clair qu'auparavant, où une action n'avait aucune connaissance de son contexte.
Je ne comprends pas pourquoi tu parles d'indétermination.
Qu'il y ait une variabilité accrue, je te le concède, mais l'action à toute les informations pour déterminer son contexte.

et ce genre d'opération ne peut conduire qu'à cette situation de bugs en rafale.

c'est un peu exagéré...

Je ne comprends toujours pas ce qu'on gagne en echange, et je redis qu'ils faut abandonner ce truc là.

On y gagne
- qu'une action connait son contexte
- qu'une action lancée depuis ecrire/ bénéficie du même niveau de sécurité que la page depuis laquelle le lien a été lancé
- qu'une action ne se trompe pas de langue (en répondant avec la langue publique à une action lancée depuis l'espace privé)
- que les redirections post-actions marchent aussi bien que l'on appelle l'action depuis l'espace privé ou depuis l'espace publique et qu'on évite les bugs systématiques de changement de répertoire lors de la redirection. C'est particulièrement flagrant dès qu'on développe des interfaces et des actions utilisables dans l'espace privé et dans l'espace publique.

Cédric

4

Je ne compte plus le nombre de bugs que ce laxisme concernant les URLs des actions a introduits.

Le laxisme n'est il pas plutôt qu'on accepte de faire une opération de modification en base de donnée sans être identifié ?

Si finalement toute action exige authentification, alors le calcul de hash est une complexité inutile: autant refaire le calcul de droit qui a été fait avant de calculer le hash.

et ce genre d'opération ne peut conduire qu'à cette situation de bugs en rafale.

c'est un peu exagéré...

malheureusement l'histoire démontre le contraire

Je ne comprends toujours pas ce qu'on gagne en echange, et je redis qu'ils faut abandonner ce truc là.

On y gagne
- qu'une action connait son contexte

C'est totalement faux. Auparavant le contexte d'une action était à la racine, maintenant ce n'est plus forcément le cas: le code PHP ne connait pas plus son contexte qu'avant, en revanche le lecteur du code ne le sait plus. D'où une difficulté supplémentaire à garantir la cohérence du code, ce dont ces bugs en rafale témoigne.

- qu'une action lancée depuis ecrire/ bénéficie du même niveau de sécurité que la page depuis laquelle le lien a été lancé

justement la mécanique de la clé de hash permettait de sécuriser dans l'espace privé une action à faire éventuellement dans l'espace public. On a perdu cette possibilité. C'est une régression fonctionnelle.

- qu'une action ne se trompe pas de langue (en répondant avec la langue publique à une action lancée depuis l'espace privé)

Les actions doivent être muettes. Les rares exceptions sont des erreurs de méthode qui doivent être évacuées, ce qu'on a presqu'entièrement fini de faire.

- que les redirections post-actions marchent aussi bien que l'on appelle l'action depuis l'espace privé ou depuis l'espace publique et qu'on évite les bugs systématiques de changement de répertoire lors de la redirection. C'est particulièrement flagrant dès qu'on développe des interfaces et des actions utilisables dans l'espace privé et dans l'espace publique.

Autrement dit on autorise les programmeurs à rédiger n'importe comment. C'est justement ça qui me contrarie depuis le début: cette architecture non déterministe incite à ne pas réfléchir, et ça par définition c'est la porte ouverte à des bugs, à l'obligation d'effectuer des tests 2 fois plus nombreux, et se mettre dans l'impossibilité de garantir certains comportements. Quand en plus ces bugs potentiels se traduisent par une floppée interminable de bugs bien réels formant une régression des fonctionnalités usuelles de SPIP, on se dit que cette idée n'est rien d'autre qu'une regression qu'il faut définitivement éliminer.

Montre moi un bout de code qu'il ne serait pas possible de faire dans l'architecture ancienne et je serai convaincu. D'ici là, il faut renoncer à ce truc.

Emmanuel

5

Committo,Ergo:sum <esj@rezo.net> a écrit :

Si finalement toute action exige authentification, alors le
calcul de hash est une complexité inutile: autant refaire
le calcul de droit qui a été fait avant de calculer le
hash.

[...]

justement la mécanique de la clé de hash permettait de
sécuriser dans l'espace privé une action à faire
éventuellement dans l'espace public. On a perdu cette
possibilité. C'est une régression fonctionnelle.

heu... si je peux me permettre de glisser mon grain de sel de pôv dev de plugins dans votre discussion hyper-technique?

Pour avoir utilisé récemment un ?action=... à partir du pompage d'un plugin de Cedric (snippets pour ne pas le citer), ça m'a mis la misère cette histoire de hash et de securiser_action: j'ai vraiment tatonné en essayant de comprendre le code existant mais ça dépassait manifestement mes capacités! Du coup j'ai préféré assurer en ajoutant après:
if (!autoriser(...l'action en question...) die _T('avis_non_acces_page'));
...et je garde quand même l'impression que sur cette partie du code du plugin je laisse un truc pas clair et/ou pas sécurisé!

Alors je sais pas ce que vous déciderez à la fin mais ce qui me semble indispensable, c'est que ça soit compréhensible et/ou explicité quelque part pour que les ceusses qui rament dans le code des gourous ils aient les moyens de pas laisser des trous de sécu de partout!

à bientôt

6

Le bazar a pour cause certaines config de PHP où open_base_dir oblige certaines action décidées dans l'espace privé à être exécutée dans l'espace public, d'où une redirection vers celui-ci avec une clé d'autorisation puisque l'espace public ne demande pas d'authentification, donc ne permet pas d'utiliser autoriser(). Le fait de marcher par redirection est par ailleurs une bonne chose, car ça obéit au modèle REST (avant, on avait le phénomène que quand on rechargeait certaines pages, le navigateur réexpédiait au serveur le formulaire remplit au coup d'avant).

Ces configurations de PHP tendant à disparaître, Cédric en a profité pour que les redirections débouchent de là où elles partent, plutôt que dans l'espace public systématiquement. Malheureusement le code de SPIP est bourré d'actions qui font l'hypothèse implicite qu'elles sont exécutées dans l'espace public. Un an plus tard on a toujours des bugs qui émergent à cause de ça. Je trouve débile de causer des régressions dans SPIP pour permettre aux programmeurs de ne pas réfléchir à ce qu'ils font.

Emmanuel

7

Committo,Ergo:sum a écrit :

Je ne compte plus le nombre de bugs que ce laxisme concernant les URLs des actions a introduits.

Le laxisme n'est il pas plutôt qu'on accepte de faire une opération de modification en base de donnée sans être identifié ?

Si finalement toute action exige authentification, alors le calcul de hash est une complexité inutile: autant refaire le calcul de droit qui a été fait avant de calculer le hash.

C'est une question légitime. Toutes les actions sont supposées être sujettes à autorisation, et il a déjà été dit que chacune devrait être sécurisée par un appel à autoriser() qui suppose l'authentification de l'auteur connecté.

Mais quelle que soit la réponse à cette question, cela n'a pas d'incidence avec l'execution des actions dans ecrire/ qui peut aussi se faire sans authentification en remontants l'appel à
traiter_appels_actions()
avant la ligne 30
dans http://trac.rezo.net/trac/spip/browser/spip/ecrire/index.php

et ce genre d'opération ne peut conduire qu'à cette situation de bugs en rafale.

c'est un peu exagéré...

malheureusement l'histoire démontre le contraire

Je dois avoir mauvaise mémoire alors.
J'ai bien noté que chaque fois cela a été l'occasion de dénoncer ce fonctionnement. Mais j'ai surtout vu que cela avait révélé des bugs latents qui se seraient manifestés autrement à un moment ou à un autre (typiquement la signification de #URL_ARTICLE dans un squelette executé dans l'espace privé ...)

Je ne comprends toujours pas ce qu'on gagne en echange, et je redis qu'ils faut abandonner ce truc là.

On y gagne
- qu'une action connait son contexte

C'est totalement faux. Auparavant le contexte d'une action était à la racine, maintenant ce n'est plus forcément le cas: le code PHP ne connait pas plus son contexte qu'avant, en revanche le lecteur du code ne le sait plus.

Tu parles du contexte d'execution (à la racine ou dans ecrire/), que l'action peut connaitre par un simple test_espace_prive()
Je parles du contexte d'appel (le contexte dans lequel le lien a été cliqué), qu'il était impossible de connaitre avec l'ancienne méthode, alors que dans l'actuelle il est le même que celui d'execution. Ceci était particulièrement pénible pour la redirection post action qui la plupart du temps ne marchait que dans un contexte donné.

D'où une difficulté supplémentaire à garantir la cohérence du code, ce dont ces bugs en rafale témoigne.

L'ensemble des fonctions de spip sont suceptibles d'être appelées depuis la racine ou depuis ecrire/, et le prévoient dans leur code.
Je ne vois pas en quoi étendre cette règle aux actions est une nouvelle difficulté.

- qu'une action lancée depuis ecrire/ bénéficie du même niveau de sécurité que la page depuis laquelle le lien a été lancé

justement la mécanique de la clé de hash permettait de sécuriser dans l'espace privé une action à faire éventuellement dans l'espace public. On a perdu cette possibilité. C'est une régression fonctionnelle.

Non, on peut toujours lancer une action dans le public depuis l'espace privé si on le souhaite, mais ce n'est plus le fonctionnement par défaut.
http://trac.rezo.net/trac/spip/browser/spip/ecrire/inc/utils.php#L1020
en passant public=true tu peux forcer explicitement une action à se dérouler dans le public.

- qu'une action ne se trompe pas de langue (en répondant avec la langue publique à une action lancée depuis l'espace privé)

Les actions doivent être muettes. Les rares exceptions sont des erreurs de méthode qui doivent être évacuées, ce qu'on a presqu'entièrement fini de faire.

Il reste alors 42 appels à _T() dans actions/

- que les redirections post-actions marchent aussi bien que l'on appelle l'action depuis l'espace privé ou depuis l'espace publique et qu'on évite les bugs systématiques de changement de répertoire lors de la redirection. C'est particulièrement flagrant dès qu'on développe des interfaces et des actions utilisables dans l'espace privé et dans l'espace publique.

Autrement dit on autorise les programmeurs à rédiger n'importe comment. C'est justement ça qui me contrarie depuis le début: cette architecture non déterministe incite à ne pas réfléchir, et ça par définition c'est la porte ouverte à des bugs, à l'obligation d'effectuer des tests 2 fois plus nombreux, et se mettre dans l'impossibilité de garantir certains comportements.

Sur le fond, je suis bien d'accord avec toi qu'avoir deux contextes possible d'execution (depuis la racine et depuis ecrire/) de l'ensemble du code de SPIP ne facilite pas les choses.
Mais bloquer le contexte pour une partie du code uniquement deplace le problème aux frontières, sans le résoudre pour autant.

Quand en plus ces bugs potentiels se traduisent par une floppée interminable de bugs bien réels formant une régression des fonctionnalités usuelles de SPIP, on se dit que cette idée n'est rien d'autre qu'une regression qu'il faut définitivement éliminer.

La régression est indépendante de ce choix, ainsi que je l'indique en début de mail.

Montre moi un bout de code qu'il ne serait pas possible de faire dans l'architecture ancienne et je serai convaincu. D'ici là, il faut renoncer à ce truc.

L'enjeu n'est ni plus ni moins que de pouvoir écrire des interfaces d'administration en squelettes qui fonctionnent identiquement dans ecrire/ et à la racine.
L'interface de modération des forums en est un exemple, et l'execution de l'action dans le meme contexte que la page appelante permet à un simple lien comme celui là de fonctionner dans tous les cas (à la racine, ou dans ecrire/)
<a class='ajax valider' href='#URL_ACTION_AUTEUR{instituer_lot_forum,publie-#GET{selection},#SELF}'><:forum:icone_valider_messages:></a>

Cédric

8

Toutes les actions sont supposées être sujettes à autorisation, et il a déjà été dit que chacune devrait être sécurisée par un appel à autoriser() qui suppose l'authentification de l'auteur connecté.

Où cela a-t-il été dit ? Pendant 7 ans SPIP a fonctionné autrement !

Mais quelle que soit la réponse à cette question, cela n'a pas d'incidence avec l'execution des actions dans ecrire/ qui peut aussi se faire sans authentification en remontants l'appel à
traiter_appels_actions()
avant la ligne 30
dans http://trac.rezo.net/trac/spip/browser/spip/ecrire/index.php

Ca fait un an qu'à chaque nouveau bug causé par ça, tu réponds "il suffit de".
Fais-le, une fois de plus on va voir que ce n'était pas si simple, et quand tu auras fini, rajoute ça à la liste du temps perdu à cause de ce changement, et compare avec le temps que tu as "gagné" grâce à lui.

J'ai bien noté que chaque fois cela a été l'occasion de dénoncer ce fonctionnement. Mais j'ai surtout vu que cela avait révélé des bugs latents qui se seraient manifestés autrement à un moment ou à un autre (typiquement la signification de #URL_ARTICLE dans un squelette executé dans l'espace privé ...)

Extraordinaire: tu crées des bugs, et tu dis qu'en fait c'est parce qu'ils étaient latents!
Tu prends le pb complètement à l'envers: SPIP a été écrit d'une certaine manière,
si on veut éviter de créer des bugs en rafale on ne peut pas remettre en question un principe vieux de 7 ans sur un coup de tête.

Tu parles du contexte d'execution (à la racine ou dans ecrire/), que l'action peut connaitre par un simple test_espace_prive()
Je parles du contexte d'appel (le contexte dans lequel le lien a été cliqué), qu'il était impossible de connaitre avec l'ancienne méthode, alors que dans l'actuelle il est le même que celui d'execution. Ceci était particulièrement pénible pour la redirection post action qui la plupart du temps ne marchait que dans un contexte donné.

C'est sur ce point qu'on s'oppose totalement: il est anormal et dangereux qu'une action ait besoin de connaître le contexte dans lequel elle a été déclenchée. Elle doit pouvoir s'exécuter indépendamment des requêtes qui l'ont précédée. Implicitement tu te fies à une variable globale pour différencier des situations, et les variables globales sont des mines de bugs par construction.

D'où une difficulté supplémentaire à garantir la cohérence du code, ce dont ces bugs en rafale témoigne.

L'ensemble des fonctions de spip sont suceptibles d'être appelées depuis la racine ou depuis ecrire/, et le prévoient dans leur code.
Je ne vois pas en quoi étendre cette règle aux actions est une nouvelle difficulté.

Parce que leur code est déjà écrit, et qu'on perd du temps à le réécrire, sans aucune contrepartie.

en passant public=true tu peux forcer explicitement une action à se dérouler dans le public.

vachement clair.

Il reste alors 42 appels à _T() dans actions/

Ils doivent disparaître de toutes façons.

Sur le fond, je suis bien d'accord avec toi qu'avoir deux contextes possible d'execution (depuis la racine et depuis ecrire/) de l'ensemble du code de SPIP ne facilite pas les choses.

ah tout de même

Mais bloquer le contexte pour une partie du code uniquement deplace le problème aux frontières, sans le résoudre pour autant.

La moitié de tests à faire en moins, ça compte pas ?

Quand en plus ces bugs potentiels se traduisent par une floppée interminable de bugs bien réels formant une régression des fonctionnalités usuelles de SPIP, on se dit que cette idée n'est rien d'autre qu'une regression qu'il faut définitivement éliminer.

La régression est indépendante de ce choix, ainsi que je l'indique en début de mail.

je ne comprends pas à quoi tu fais référence.

L'enjeu n'est ni plus ni moins que de pouvoir écrire des interfaces d'administration en squelettes qui fonctionnent identiquement dans ecrire/ et à la racine.

Cette affirmation est doublement absurde. D'une part ecrire/ exige authentification tandis que la racine ne le fait pas; la méthode par clé de hash est le moyen d'avoir qqch qui fonctionne sans authentification pour les deux. Je ne vois pas ce que tu apportes de neuf. D'autre part, si ça fonctionne à l'identique, quel besoin y a-t-il de forcer les actions déclenchées dans ecrire/ à s'exécuter de même ? Au vrai, tu as à présent 2 codes dans tes actions, ce qui n'était pas le cas auparavant. Où est le progrès ?

Emmanuel

9

[...]

Sur le fond, je suis bien d'accord avec toi qu'avoir deux contextes possible d'execution (depuis la racine et depuis ecrire/) de l'ensemble du code de SPIP ne facilite pas les choses.

ah tout de même

Mais bloquer le contexte pour une partie du code uniquement deplace le problème aux frontières, sans le résoudre pour autant.

La moitié de tests à faire en moins, ça compte pas ?

Quand en plus ces bugs potentiels se traduisent par une floppée interminable de bugs bien réels formant une régression des fonctionnalités usuelles de SPIP, on se dit que cette idée n'est rien d'autre qu'une regression qu'il faut définitivement éliminer.

La régression est indépendante de ce choix, ainsi que je l'indique en début de mail.

je ne comprends pas à quoi tu fais référence.

L'enjeu n'est ni plus ni moins que de pouvoir écrire des interfaces d'administration en squelettes qui fonctionnent identiquement dans ecrire/ et à la racine.

Cette affirmation est doublement absurde. D'une part ecrire/ exige authentification tandis que la racine ne le fait pas;

Ce n'est pas vrai.

Par exemple, les forums sur abonnement, qui sont à la racine et non dans "ecrire/", exigent l'authentification.

Je crois qu'il faudrait tout simplement arrêter de lier "authentification" et "type d'interface" (consultation ou gestion), d'autant plus qu'on veut de plus en plus faire de la gestion directement sur le site, comme avec les crayons.

-Nicolas

10

ESJ a écrit :

Autrement dit on autorise les programmeurs à rédiger n'importe comment. C'est justement ça qui me contrarie depuis le début: cette architecture non déterministe incite à ne pas réfléchir, et ça par définition c'est la porte ouverte à des bugs, à l'obligation d'effectuer des tests 2 fois plus nombreux, et se mettre dans l'impossibilité de garantir certains comportements.

Cédric a écrit :

C'est une question légitime. Toutes les actions sont supposées être
sujettes à autorisation, et il a déjà été dit que chacune devrait être
sécurisée par un appel à autoriser() qui suppose l'authentification de
l'auteur connecté.

Bon alors ça tombe bien, parce que personnellement moi-même, en tant que développeur utilisateur des ficelles de SPIP, et qui réfléchit quand même un peu de temps à temps à ce qu'il écrit, j'étais justement en plein dans ces questionnements.

En ayant lu la doc sur les actions sécurisés de programmer.spip.org, je comprends que cela permet de dire : "la personne qui exécute l'action est bien Monsieur Machin".

Mais à aucun moment on ne sait si Monsieur Machin à le *droit* d'exécuter cette action.

J'en conclue que de toute façon il faut placer un "autoriser()" quelque part.

11

Committo,Ergo:sum a écrit :

Toutes les actions sont supposées être sujettes à autorisation, et il a déjà été dit que chacune devrait être sécurisée par un appel à autoriser() qui suppose l'authentification de l'auteur connecté.

Où cela a-t-il été dit ? Pendant 7 ans SPIP a fonctionné autrement !

Mais quelle que soit la réponse à cette question, cela n'a pas d'incidence avec l'execution des actions dans ecrire/ qui peut aussi se faire sans authentification en remontants l'appel à
traiter_appels_actions()
avant la ligne 30
dans http://trac.rezo.net/trac/spip/browser/spip/ecrire/index.php

Ca fait un an qu'à chaque nouveau bug causé par ça, tu réponds "il suffit de".

c'est bien connu, je suis le chantre du yakafokon qui attends que les autres fassent ...

Fais-le, une fois de plus on va voir que ce n'était pas si simple, et quand tu auras fini, rajoute ça à la liste du temps perdu à cause de ce changement, et compare avec le temps que tu as "gagné" grâce à lui.

je ne dis pas que j'aurais gagné du temps au final (et je suis bien conscient que c'est le contraire qui se produit), mais j'ose espérer qu'on aura gagné en souplesses et en fonctionnalités.
Il me semble que l'exemple de l'interface de modération des forums est éloquent à ce sujet, pourtant ...

J'ai bien noté que chaque fois cela a été l'occasion de dénoncer ce fonctionnement. Mais j'ai surtout vu que cela avait révélé des bugs latents qui se seraient manifestés autrement à un moment ou à un autre (typiquement la signification de #URL_ARTICLE dans un squelette executé dans l'espace privé ...)

Extraordinaire: tu crées des bugs, et tu dis qu'en fait c'est parce qu'ils étaient latents!

hum, c'est un peu fort de café ... En ce qui concerne le #URL_ARTICLE, je ferais remarquer que sa définition n'avait jamais été définie explicitement en cas d'utilisation dans le privé, et qu'à l'occasion de changement opérés dans les modules url/, son comportement a changé à deux reprises.
On peut donc voir les choses de plusieurs manières bien différentes ...

Tu prends le pb complètement à l'envers: SPIP a été écrit d'une certaine manière,

qui correspondait à une réalité certaine.
Ce qui a changé entre temps est la possibilité de réécrire l'interface utilisateur de l'espace privé sous forme de squelette. Et la moindre des choses est que ces squelettes soient réutilisables dans le site public pour permettre à ceux qui le veulent de reconstruire des interfaces sur mesures.
C'est une démarche de plus en plus courante.

si on veut éviter de créer des bugs en rafale on ne peut pas remettre en question un principe vieux de 7 ans sur un coup de tête.

Chaque nouvelle utilisation d'une action depuis l'interface me conforte dans le bien fondé de ce choix.

Tu parles du contexte d'execution (à la racine ou dans ecrire/), que l'action peut connaitre par un simple test_espace_prive()
Je parles du contexte d'appel (le contexte dans lequel le lien a été cliqué), qu'il était impossible de connaitre avec l'ancienne méthode, alors que dans l'actuelle il est le même que celui d'execution. Ceci était particulièrement pénible pour la redirection post action qui la plupart du temps ne marchait que dans un contexte donné.

C'est sur ce point qu'on s'oppose totalement: il est anormal et dangereux qu'une action ait besoin de connaître le contexte dans lequel elle a été déclenchée. Elle doit pouvoir s'exécuter indépendamment des requêtes qui l'ont précédée.

C'est bien vrai, à l'exception pres de la redirection qui pose tout un tas de problèmes lorsqu'on s'amuse à executer les actions systématiquement dans le public.

Implicitement tu te fies à une variable globale pour différencier des situations, et les variables globales sont des mines de bugs par construction.

En ce qui me concerne, les seuls cas qui necessitent une attention particulière sont les accès fichiers, qui sont traités sans problème par l'utilisation des _DIR_...

D'où une difficulté supplémentaire à garantir la cohérence du code, ce dont ces bugs en rafale témoigne.

L'ensemble des fonctions de spip sont suceptibles d'être appelées depuis la racine ou depuis ecrire/, et le prévoient dans leur code.
Je ne vois pas en quoi étendre cette règle aux actions est une nouvelle difficulté.

Parce que leur code est déjà écrit, et qu'on perd du temps à le réécrire, sans aucune contrepartie.

la contrepartie est l'écriture d'interface utilisables indistinctement dans ecrire/ et dans le public (eventuellement sous reserve d'authentification)

en passant public=true tu peux forcer explicitement une action à se dérouler dans le public.

vachement clair.

Il reste alors 42 appels à _T() dans actions/

Ils doivent disparaître de toutes façons.

Sur le fond, je suis bien d'accord avec toi qu'avoir deux contextes possible d'execution (depuis la racine et depuis ecrire/) de l'ensemble du code de SPIP ne facilite pas les choses.

ah tout de même

Mais bloquer le contexte pour une partie du code uniquement deplace le problème aux frontières, sans le résoudre pour autant.

La moitié de tests à faire en moins, ça compte pas ?

C'est faux, ça ne réduisait pas les tests, ça ne faisait que déplacer le problème dans les redirections.

Quand en plus ces bugs potentiels se traduisent par une floppée interminable de bugs bien réels formant une régression des fonctionnalités usuelles de SPIP, on se dit que cette idée n'est rien d'autre qu'une regression qu'il faut définitivement éliminer.

La régression est indépendante de ce choix, ainsi que je l'indique en début de mail.

je ne comprends pas à quoi tu fais référence.

on peut tout aussi bien choisir de rétablir les actions sans authentification, indépendamment de leur execution depuis ecrire/. Et réciproquement.

L'enjeu n'est ni plus ni moins que de pouvoir écrire des interfaces d'administration en squelettes qui fonctionnent identiquement dans ecrire/ et à la racine.

Cette affirmation est doublement absurde. D'une part ecrire/ exige authentification tandis que la racine ne le fait pas; la méthode par clé de hash est le moyen d'avoir qqch qui fonctionne sans authentification pour les deux. Je ne vois pas ce que tu apportes de neuf. D'autre part, si ça fonctionne à l'identique, quel besoin y a-t-il de forcer les actions déclenchées dans ecrire/ à s'exécuter de même ?

les redirections post actions qui n'arrêtaient pas de se prendre les pieds dans le tapis ...

Au vrai, tu as à présent 2 codes dans tes actions, ce qui n'était pas le cas auparavant. Où est le progrès ?

le progrès est que là ou tu avais un code php fonctionnel uniquement dans ecrire/
http://trac.rezo.net/trac/spip/browser/spip/ecrire/inc/forum.php?rev=12473#L167
à cause d'un _DIR_RESTREINT_ABS en dur dans le code

on a la même chose en squelettes dans

et plus particulièrement dans

qui fonctionne indifféremment selon l'endroit où il est executé.

Je veux bien qu'on me dise que je fais des modifs sur un coup de tête, que tout ça est une hérésie etc ...
Tout ce que je vois est que la refonte de l'espace privé en squelettes est un chantier récurrent dont tout le monde parle et que tout le monde réclame depuis longtemps, mais que dans les faits je suis presque le seul à m'y coller au quotidien.
Dans la pratique, il y a eu pas mal de petits obstacles qui rendaient cette écriture lourde et rebutante, que j'ai essayé de résoudre au mieux au fur et à mesure. Les redirections après action en étaient une du fait de passage systématique par la racine.

Vu de ton côté de la lorgnette, c'est peut être avant tout une gêne qui a cassé certaines compatibilités. Mais ça n'est pas gratuit, et ça a un bénéfice réel et tangible.

Cédric

12

Ca fait un an qu'à chaque nouveau bug causé par ça, tu réponds "il suffit de".

c'est bien connu, je suis le chantre du yakafokon qui attends que les autres fassent ...

ce n'est pas ce que je sous-entendais, ne sépare pas cette phrase de ce que je dis ensuite:

Fais-le, une fois de plus on va voir que ce n'était pas si simple, et quand tu auras fini, rajoute ça à la liste du temps perdu à cause de ce changement, et compare avec le temps que tu as "gagné" grâce à lui.

hum, c'est un peu fort de café ... En ce qui concerne le #URL_ARTICLE, je ferais remarquer que sa définition n'avait jamais été définie explicitement en cas d'utilisation dans le privé, et qu'à l'occasion de changement opérés dans les modules url/, son comportement a changé à deux reprises.

Une balise n'a pas à dépendre du contexte dans laquelle elle est utilisée, en soi ça n'a rien à voir avec le pb dont on parle.

Tu prends le pb complètement à l'envers: SPIP a été écrit d'une certaine manière,

qui correspondait à une réalité certaine.
Ce qui a changé entre temps est la possibilité de réécrire l'interface utilisateur de l'espace privé sous forme de squelette.

Bien sûr, mais la question est de savoir si le laxisme que tu as introduit est indispensable à cette tâche.

C'est sur ce point qu'on s'oppose totalement: il est anormal et dangereux qu'une action ait besoin de connaître le contexte dans lequel elle a été déclenchée. Elle doit pouvoir s'exécuter indépendamment des requêtes qui l'ont précédée.

C'est bien vrai, à l'exception pres de la redirection qui pose tout un tas de problèmes lorsqu'on s'amuse à executer les actions systématiquement dans le public.

Peux-tu lister précisément ces problèmes, tant que je ne les verrais pas je ne serais pas convaincu.

Implicitement tu te fies à une variable globale pour différencier des situations, et les variables globales sont des mines de bugs par construction.

En ce qui me concerne, les seuls cas qui necessitent une attention particulière sont les accès fichiers, qui sont traités sans problème par l'utilisation des _DIR_...

alors ce tas de problème se réduit à un seul ?

la contrepartie est l'écriture d'interface utilisables indistinctement dans ecrire/ et dans le public (eventuellement sous reserve d'authentification)

Tu confonds l'effet et la cause. Oui il faut écrire de telles interfaces, mais on pourrait le faire même si l'indéterminisme que tu as introduit était évacué.

La moitié de tests à faire en moins, ça compte pas ?

C'est faux, ça ne réduisait pas les tests, ça ne faisait que déplacer le problème dans les redirections.

Mais non justement: si toutes les actions étaient exécutées au même endroit, elles ne nécessiterait qu'un seul test, car on n'aurait pas à tenir compte de leur contexte, c'est bien ça qui est un signe de robustesse.

on peut tout aussi bien choisir de rétablir les actions sans authentification, indépendamment de leur execution depuis ecrire/. Et réciproquement.

mais ça n'a rien à voir avec le fond de la discussion.

quel besoin y a-t-il de forcer les actions déclenchées dans ecrire/ à s'exécuter de même ?

les redirections post actions qui n'arrêtaient pas de se prendre les pieds dans le tapis ...

Retour de la posture: tout faire pour que le programmeur n'ait pas à réfléchir. C'est pas bon.

Au vrai, tu as à présent 2 codes dans tes actions, ce qui n'était pas le cas auparavant. Où est le progrès ?

le progrès est que là ou tu avais un code php fonctionnel uniquement dans ecrire/

....
Tu te répètes alors moi aussi: tu confonds l'effet et la cause.

Tout ce que je vois est que la refonte de l'espace privé en squelettes est un chantier récurrent dont tout le monde parle et que tout le monde réclame depuis longtemps, mais que dans les faits je suis presque le seul à m'y coller au quotidien.

Hum, la réécriture complète (pour la 1.9) de l'espace privé selon le modèle REST, qui était un préalable indispensable, j'ai été "presque le seul à m'y coller au quotidien". Alors, ce genre d'argument ...

Vu de ton côté de la lorgnette, c'est peut être avant tout une gêne qui a cassé certaines compatibilités. Mais ça n'est pas gratuit, et ça a un bénéfice réel et tangible.

Je répète que mon souci est que le non-déterminisme que tu as introduit est générateur de bugs par construction. Ce n'est pas juste une contrariété sur des incompatibilités passagères, c'est la conviction que c'est une fausse piste.

Où cela a-t-il été dit ? Pendant 7 ans SPIP a fonctionné autrement !

Dans ma proposition du 13/01/2009 que tu as confirmée sur cette liste :

- faire reposer la sécurité des actions critiques (et à terme de toutes) sur identification+autoriser() au lieu d'un simple hash de confiance

Pff, c'est pas possible de répondre à côté tout le temps: la question est de savoir si c'est bon ou pas qu'une action soit appelée avec des valeurs de DIR_RACINE différentes. Et tu ne t'embarasses pas de contradictions en ressortant ça, puisque la modif que tu proposes dans ecrire/index.php pour que l'alea_ancien marche à nouveau consiste à justement ne plus faire d'identification dans ce cas,
alors qu'on est dans ecrire!

C'est d'ailleurs aussi ce qui me contrarie: on avait réussi à ce que ecrire/index.php soit petit et assez facile à comprendre, maintenant c'est une usine à gaz, et ta seule solution au problème du jour va être de le rendre encore plus opaque.

Emmanuel

13

Si finalement toute action exige authentification, alors le calcul de hash
est une complexité inutile: autant refaire le calcul de droit qui a été fait
avant de calculer le hash.

Hé non, il faut absolument les deux, car sinon on s'expose à une
attaque du genre je t'envoie un mail contenant une image qui pointe
vers l'action X du site dans lequel tu es connecté.

-- Fil

14

Bonjour,

> Si finalement toute action exige authentification, alors le calcul de hash
> est une complexité inutile: autant refaire le calcul de droit qui a été fait
> avant de calculer le hash.

Hé non, il faut absolument les deux, car sinon on s'expose à une
attaque du genre je t'envoie un mail contenant une image qui pointe
vers l'action X du site dans lequel tu es connecté.

-- Fil

lol, mdr !!!

Qui a un lecteur de mail qui s'autorise a aller sur le web sans permission !!!!!

<trol>C'est vrai que depuis le fameux 11 septembre : tout habitation de plus de 3m de haut peut se
faire attaquer par un avion détourner avec un cutter plastique !!!!!!!!</trol>

Sérieusement : faire sauter ce hash d'action serait une bonne chose : je voudrais faire un système de
gestion de 60+ SPIP (non mutualisé parce que je ne peux pas, IIS toussa...) et le c*#!#*d de hash me
pourri la vie (sans compter qu'il repose aussi, il me semble sur le temps !! -> masque logique de
timestamp !!!!).

15

Qui a un lecteur de mail qui s'autorise a aller sur le web sans permission !!!!!

Même si ton mail est blindé, il y a 100 manières fort peu créatives de
mener cette attaque

Sérieusement : faire sauter ce hash d'action serait une bonne chose : je voudrais faire un système de
gestion de 60+ SPIP (non mutualisé parce que je ne peux pas, IIS toussa...) et le c*#!#*d de hash me
pourri la vie (sans compter qu'il repose aussi, il me semble sur le temps !! -> masque logique de
timestamp !!!!).

Tu utilises IIS ? "lol mdr"

-- Fil

16

Un image ou n'importe quoi d'autre, tu as raison.
Et ça ne fait qu'aggraver le pb: alea_ancien ne marche plus, et tu rappelles que ce mécanisme est indispensable.

Emmanuel

17

Je reviens au message de départ, pour voir que corriger :

18

C'est en reportant dans la stable ce que j'avais fait dans la dev:
http://trac.rezo.net/trac/spip/changeset/13857
j'ai mis l'alea à 60 secondes pour tester à fond, et c'est comme ça que je l'ai découvert.

            Emmanuel

19

C'est en reportant dans la stable ce que j'avais fait dans la dev:
http://trac.rezo.net/trac/spip/changeset/13857
j'ai mis l'alea à 60 secondes pour tester à fond, et c'est comme ça que je
l'ai découvert.

OK. Maintenant la bonne question : est-ce que tu as attendu 61s entre
l'affichage d'une page et le clic sur l'action ? Si oui tu as vécu 2
changements d'alea, et là c'est normal d'être déconnecté.

-- Fil

20

Non, moins, et d'ailleurs Cédric ne me contredit pas sur le fait que maintenant qu'on passe par ecrire/index.php l'authentification rentre en action, et elle elle n'exploite pas l'alea ancien.

Emmanuel