Je suis dans un contexte de serveur avec un load-balancing et l’ip qui remonte est toujours l’ip d’un serveur du réseau.
Le jeton ne change pas si on ne recalcul pas la page, ce n’est pas un problème de #INCLURE car le site est réaliser avec noisetier.
Je suis dans un contexte de serveur avec un load-balancing et l'ip qui
remonte est toujours l'ip d'un serveur du réseau.
Le jeton ne change pas si on ne recalcul pas la page, ce n'est pas un
problème de #INCLURE car le site est réaliser avec noisetier.
Amha le problème est du côté de la conf de ton loadbalancer qui devrait faire passer l'ip originale au serveur qui est derrière lui, à coup de X-Forwarded-For car SPIP prend déjà ça en charge cf :
Ajoute $jeton dans le log pour voir, mais je pense que tu as bien un jeton, il est juste plus valide parce qu’il a été mis en cache à cause d’un modele ou d’un #INCLURE, ou d’une mise en cache abusive en amont par ton load-balancer ou reverse-proxy
Il est censé être dynamique est regénéré à chaque affichage du formulaire, et valide 1h, ce qui normalement est un temps suffisant pour qu’un utilisateur saisisse les infos dans le formulaire.
--
Cédric
Le 27 juin 2019 à 11:48 +0200, Pierre KUHN <pierrekuhn82@gmail.com>, a écrit :
De plus cela ne ce produit pas tout le temps du coup je ne vois pas comment remonter le problème plus haut.
Des idées ?
Merci.
> Le mar. 18 juin 2019 à 15:40, Bruno Bergot <bruno@eliaz.fr> a écrit :
> > Hop,
> >
> > Le 18/06/2019 à 15:05, Pierre KUHN a écrit :
> > > Bonjour,
> > >
> > > Je suis dans un contexte de serveur avec un load-balancing et l'ip qui
> > > remonte est toujours l'ip d'un serveur du réseau.
> > > Le jeton ne change pas si on ne recalcul pas la page, ce n'est pas un
> > > problème de #INCLURE car le site est réaliser avec noisetier.
> > >
> > > Dans nospam, pour un visiteur sans compte nous utilisons $GLOBALS['ip'] ici
> > > https://zone.spip.net/trac/spip-zone/browser/spip-zone/_plugins_/nospam/inc/nospam.php#L14
> > > hors elle remonte une ip de serveur.
> > >
> >
> > Amha le problème est du côté de la conf de ton loadbalancer qui devrait
> > faire passer l'ip originale au serveur qui est derrière lui, à coup de
> > X-Forwarded-For car SPIP prend déjà ça en charge cf :
> >
> > https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc_version.php#L297
> >
> > Code qui prend déjà en charge $_SERVER['REMOTE_ADDR'] comme tu peux le voir.
> >
> > Bref, le bug ne semble pas être dans SPIP mais dans la conf de ton
> > serveur
> >
> > ++
> > b_b
Je suis sur un site avec le noisetier donc pas de #INCLURE en principe.
Je poursuis, merci.
Le jeu. 27 juin 2019 à 11:56, Cerdic <cedric@yterium.com> a écrit :
Ajoute $jeton dans le log pour voir, mais je pense que tu as bien un
jeton, il est juste plus valide parce qu’il a été mis en cache à cause d’un
modele ou d’un #INCLURE, ou d’une mise en cache abusive en amont par ton
load-balancer ou reverse-proxy
Il est censé être dynamique est regénéré à chaque affichage du formulaire,
et valide 1h, ce qui normalement est un temps suffisant pour qu’un
utilisateur saisisse les infos dans le formulaire.
--
Cédric
Le 27 juin 2019 à 11:48 +0200, Pierre KUHN <pierrekuhn82@gmail.com>, a
écrit :
De plus cela ne ce produit pas tout le temps du coup je ne vois pas
comment remonter le problème plus haut.
Des idées ?
Merci.
Le mar. 18 juin 2019 à 15:40, Bruno Bergot <bruno@eliaz.fr> a écrit :
Hop,
Le 18/06/2019 à 15:05, Pierre KUHN a écrit :
> Bonjour,
>
> Je suis dans un contexte de serveur avec un load-balancing et l'ip qui
> remonte est toujours l'ip d'un serveur du réseau.
> Le jeton ne change pas si on ne recalcul pas la page, ce n'est pas un
> problème de #INCLURE car le site est réaliser avec noisetier.
>
> Dans nospam, pour un visiteur sans compte nous utilisons $GLOBALS['ip']
ici
> https://zone.spip.net/trac/spip-zone/browser/spip-zone/_plugins_/nospam/inc/nospam.php#L14
> hors elle remonte une ip de serveur.
>
Amha le problème est du côté de la conf de ton loadbalancer qui devrait
faire passer l'ip originale au serveur qui est derrière lui, à coup de
X-Forwarded-For car SPIP prend déjà ça en charge cf :
Je suis sur un site avec le noisetier donc pas de #INCLURE en principe.
Bé si justement.
C'est un des problèmes que j'avais remonté à Éric quand il a fait la
refonte.
Déjà moi j'arrive pas à voir dans quel cas ça serait indispensable
d'avoir une inclusion statique de noisettes, donc pour moi ça devrait
même pas être configurable, ça devrait toujours être dynamique. Mais en
plus, là on peut le choisir ET c'était statique par défaut !
Moi je suis d'avis que :
1) on devrait enlever le choix et ça devrait toujours être dynamique
2) si vraiment on doit laisser le choix, ça DOIT être dynamique par
défaut, on ne doit rien avoir à rajouter pour ça, et c'est seulement
quand on veut du statique qu'on le dit
Pour moi clairement ce choix ne va pas, ça doit absolument être
dynamique par défaut. Cédric a toujours expliqué qu'on devait toujours
mettre <INCLURE>, et que seulement dans quelques cas hyper rare en ayant
bien réfléchi on décide de mettre #INCLURE : n-core et le noizetier
doivent suivre cette règle.
J’ai trouvé dans le code des #INCLURE que j’ai replacer en <INCLURE mais cela semble pas corrigé le problème.
Le site est avec memcached et varnish et nous avons pas le problème si on vide les 2 caches.
Le problème se trouverais donc à ce niveau je pense mais comment le trouver ou bien mettre en place les logs au bon endroit pour avoir des infos.
