meta cache_signature trop restrictive #3988

Closed
opened 6 years ago by miros · 8 comments
miros commented 6 years ago

La meta cache_signature n'envisage pas que la base puisse être utilisée avec plusieurs caches différents. Cette situation peut exister si on a plusieurs VirtualHost utilisant la même base, ou bien si une base est répliquée entre plusieurs machines servant le même site (installation haute dispo).

L'utilisation de la même meta pour contrôler plusieurs caches va provoquer soit des recalculs inutiles, soit des conflits de réplication de base de donnée.

Le problème peut être évité en suffixant le nom de la meta par un identifiant dépendant du VirtualHost et de la machine. Le patch ci-joint implémente cette modification.

La meta cache_signature n'envisage pas que la base puisse être utilisée avec plusieurs caches différents. Cette situation peut exister si on a plusieurs VirtualHost utilisant la même base, ou bien si une base est répliquée entre plusieurs machines servant le même site (installation haute dispo). L'utilisation de la même meta pour contrôler plusieurs caches va provoquer soit des recalculs inutiles, soit des conflits de réplication de base de donnée. Le problème peut être évité en suffixant le nom de la meta par un identifiant dépendant du VirtualHost et de la machine. Le patch ci-joint implémente cette modification.
Owner

Bonjour

Merci pour le patch.

Est il possible de le proposer en tant que pull request sur
https://git.spip.net/SPIP/spip (compte de la zone) ou bien sur le
clone public http://github.com/spip/spip ?

Bonjour Merci pour le patch. Est il possible de le proposer en tant que pull request sur https://git.spip.net/SPIP/spip (compte de la zone) ou bien sur le clone public http://github.com/spip/spip ?
Poster

Est il possible de le proposer en tant que pull request sur
https://git.spip.net/SPIP/spip (compte de la zone) ou bien sur le
clone public http://github.com/spip/spip ?

C'est fait:
https://github.com/spip/SPIP/pull/26

Est-ce que je dois lancer des pull requests pour les branches de SPIP?

--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu`netbsd.org

> Est il possible de le proposer en tant que pull request sur > https://git.spip.net/SPIP/spip (compte de la zone) ou bien sur le > clone public http://github.com/spip/spip ? C'est fait: https://github.com/spip/SPIP/pull/26 Est-ce que je dois lancer des pull requests pour les branches de SPIP? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu`netbsd.org
Owner

bonjour

Merci pour le PR. Pour le moment il faut mieux faire sur la
trunk/master, le report sur les branches est à avoir au cas par cas.

Je suis preneur d'un relecteur de code pour valider le PR.

bonjour Merci pour le PR. Pour le moment il faut mieux faire sur la trunk/master, le report sur les branches est à avoir au cas par cas. Je suis preneur d'un relecteur de code pour valider le PR.
Owner

je vais regarder, mais je pense que la PR ne doit pas être appliquée en l'état :

  • les caches sont déjà distingués en fonction du host qui sert à accéder au site, via le contexte implicite du cache, qui sert à définir l'identifiant de mise en cache (donc 2 hits sur la meme page via 2 host différents tomberont sur 2 identifiants différents)

Le cas qui peut être problématique est celui de la base répliquée entre plusieurs serveurs, mais là on entre dans un autre sujet et pour qu'il y ait collision cela supposerait que le dossier tmp/cache est commun aux serveurs. Ce qui semble une mauvaise idée si chaque serveur à sa base (répliquées avec possibles désynchro ?). Dans ce cas il suffit de définir un dossier cache sur chaque machine (via un `define('_DIR_CACHE',...) qui tape dans un dossier qui n'est pas partagé).

Si le problème vient d'une utilisation de memoization (cache via memcached ou autre), alors ce n'est pas ici qu'il faut en parler car ça ne concerne pas le core

je vais regarder, mais je pense que la PR ne doit pas être appliquée en l'état : * les caches sont déjà distingués en fonction du host qui sert à accéder au site, via le contexte implicite du cache, qui sert à définir l'identifiant de mise en cache (donc 2 hits sur la meme page via 2 host différents tomberont sur 2 identifiants différents) Le cas qui peut être problématique est celui de la base répliquée entre plusieurs serveurs, mais là on entre dans un autre sujet et pour qu'il y ait collision cela supposerait que le dossier tmp/cache est commun aux serveurs. Ce qui semble une mauvaise idée si chaque serveur à sa base (répliquées avec possibles désynchro ?). Dans ce cas il suffit de définir un dossier cache sur chaque machine (via un `define('_DIR_CACHE',...) qui tape dans un dossier qui n'est pas partagé). Si le problème vient d'une utilisation de memoization (cache via memcached ou autre), alors ce n'est pas ici qu'il faut en parler car ça ne concerne pas le core
b_b commented 5 years ago
Owner

Statut changé à En cours

**Statut changé à En cours**
Poster

cedric - a écrit :

Le cas qui peut être problématique est celui de la base répliquée
entre plusieurs serveurs, mais là on entre dans un autre sujet et
pour qu'il y ait collision cela supposerait que le dossier tmp/cache
est commun aux serveurs.

On se heurte au problème dans ce contexte, mais chaque serveur
a son dossier cache. La base de donnée est partagée, sauf certaines
tables qui restent locales (jobs; syndic, urls, transactions, visites, referers).

Comme chaque machine a son cache, elle tente d'écrire la meta cache_signature avec une valeur qui rentre en conflit avec celle des autres, d'où l'idée d'avoir un nom de meta différente pour chaque cache.

cedric - a écrit : > Le cas qui peut être problématique est celui de la base répliquée > entre plusieurs serveurs, mais là on entre dans un autre sujet et > pour qu'il y ait collision cela supposerait que le dossier tmp/cache > est commun aux serveurs. On se heurte au problème dans ce contexte, mais chaque serveur a son dossier cache. La base de donnée est partagée, sauf certaines tables qui restent locales (jobs; syndic, urls, transactions, visites, referers). Comme chaque machine a son cache, elle tente d'écrire la meta cache_signature avec une valeur qui rentre en conflit avec celle des autres, d'où l'idée d'avoir un nom de meta différente pour chaque cache.
Owner

Comment ça "chaque machine tente d'écrire la meta avec une valeur qui rentre en conflit avec celle des autres" ?
On ecrit la meta qu'une seule fois dans toute la vie du site, et une fois que la meta existe elle n'est plus jamais modifiée, chaque machine devrait donc utiliser la même valeur ici, ce qui n'est absolument pas gênant

Cette signature est uniquement une sécurité anti-injection pour éviter qu'un autre site malveillant ne soit en mesure d'injecter des faux caches, elle n'intervient en rien dans la gestion du cache par lui même, qui tient déjà compte normalement des spécificités de l'instance via la fonction calculer_contexte_implicite()
https://core.spip.net/projects/spip/repository/entry/spip/ecrire/public/assembler.php#L204

Si la modification de cette signature corrige un problème avéré, il est a craindre que ce ne soit pas la bonne correction et masque en fait un autre bug.
Il faudrait donc remonter à la source du vrai problème constaté et voir ce que cela impacte et si ce n'est pas plutôt la fonction calculer_contexte_implicite() qui devrait évoluer, ce qui est à envisager avec prudence là aussi.

Comment ça "chaque machine tente d'écrire la meta avec une valeur qui rentre en conflit avec celle des autres" ? On ecrit la meta qu'une seule fois dans toute la vie du site, et une fois que la meta existe elle n'est plus jamais modifiée, chaque machine devrait donc utiliser la même valeur ici, ce qui n'est absolument pas gênant Cette signature est uniquement une sécurité anti-injection pour éviter qu'un autre site malveillant ne soit en mesure d'injecter des faux caches, elle n'intervient en rien dans la gestion du cache par lui même, qui tient déjà compte normalement des spécificités de l'instance via la fonction calculer_contexte_implicite() https://core.spip.net/projects/spip/repository/entry/spip/ecrire/public/assembler.php#L204 Si la modification de cette signature corrige un problème avéré, il est a craindre que ce ne soit pas la bonne correction et masque en fait un autre bug. Il faudrait donc remonter à la source du vrai problème constaté et voir ce que cela impacte et si ce n'est pas plutôt la fonction calculer_contexte_implicite() qui devrait évoluer, ce qui est à envisager avec prudence là aussi.
Owner

Pas de réponse à la demande de précisions
Statut changé à Fermé

Pas de réponse à la demande de précisions **Statut changé à Fermé**
Sign in to join this conversation.
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.