Bonjour,
J’ai mis à jour ce matin la nouvelle version 13.0.2 depuis une version 13.0.1
Depuis, je ne peux plus modifier les permissions. J’ai ce message "« Le jeton de sécurité a expiré… »
Pour info, je suis passé d’une version 11 à 13 il y a deux semaines environs, j’avais du deja faire la modif dans module.php afin de pouvoir configurer les modules.
Maintenant, je ne peux plus modifier les permissions.
Merci de votre aide
–
Version php 7.3.9
MySQL or MariaDB 5.5.5-10.3.27-MariaDB-0+deb10u1
Merci à vous tous, votre contribution nous aide à résoudre des problème qui sans vous serait impossible.
Un grand merci.
Bonjour,
Les problèmes de jeton de sécurité expiré viennent à 99% des modules externes.
Commencez par les désactiver.
Merci,
effectivement j’en ai beaucoup. dommage qu’ils provoquent des bugs.
Je vais les désactiver tant pis en attandant.
merci encore
Bonjour,
Pour identifier les modules qui provoquent le renouvellement intempestif, même s’il est possible d’utiliser le module « Journaux et traces » (en niveau 7 LOG_DEBUG), je trouve ça un peu fastidieux à analyser, alors j’ai deux alternatives :
NOTOKENRENEWAL. Par exemple, si votre serveur fournit un shell bash :cd /var/www/html/chemin/de/votre/dolibarr
# note : 'interface.php' est un nom donné au back-end des requêtes ajax
# de nombreux modules de Dolibarr
for file_name in $(find ./ -name *.css.php -o -name *.js.php -o -name interface.php);do
# si le fichier ne contient pas 'NOTOKENRENEWAL', affiche son nom
# -L permet d'inverser la recherche: je veux les fichiers qui ne
# correspondent PAS au motif fourni
# -H permet d’afficher le nom du fichier plutôt que des lignes
grep -LH 'NOTOKENRENEWAL' "$file_name"
# si le fichier contient 'NOTOKENRENEWAL' sur une ligne commentée
# avec //, affiche son nom aussi
# -P permet d’utiliser les expressions régulières perl
grep -PH "^[\t ]*//.*define.*NOTOKENRENEWAL" "$file_name"
done
Évidemment, on peut avoir des faux positifs (des scripts qui ne font pas appel à main.inc.php, des scripts qui ne définissent pas la constante dans leur code propre mais qui la définissent quand même ailleurs (fichier inclus, fonction…)
main.inc.php (temporairement) pour pouvoir pister les scripts qui provoquent la génération d’un jeton CSRF moins de 3 secondes* après qu’un premier jeton a été généré (en général, on reste au moins 3 secondes sur une page, donc il y a de forte chances que ces scripts-là soient les « coupables »). Vous pouvez alors vérifier à la main s’il leur manque la définition de la constante NOTOKENRENEWAL.* généralement, les utilisateurs restent au moins 3 secondes sur une page, et les requêtes vers les ressources externes sont reçues par le serveur en moins de 3 secondes. Évidemment, on peut avoir des faux positifs si l’utilisateur clique plus vite que son ombre et des faux négatifs avec des requêtes ajax qui ne seraient pas lancées tout de suite.
[edit] Désolé, j’avais copié-collé mon code bash depuis vim avec l’option list/listchars activée, ce qui fait que tous les espaces étaient remplacés par des · et les tabulations par des →.
Je viens d’avoir le même comportement dans la 15.0.2 - impossible de m’identifier, toujours « Le jeton de sécurité a expiré, aussi l’action a été annulée. Merci de ré-essayer » .
En me connectant à mon serveur je constates que son disque est plein, dans dans mon cas c’est sûrement la cause.
Il faut regarder quel fichier un peu gros remplit le disque. C’est normal que ça se remplit avec le temps, il faut entretenir son installation. A noter qu’en se connectant root sur le serveur, on a généralement 5% d’espace disque de secours en plus pour rattraper la situation avant que ça s’empire encore.
Et évidement, les sauvegardes sont à jour ?
