V13 Pb désactivation module [avec module multi-société]

vous pouvez fair un test tous les deux ?

passez temporairement la variable $dolibarr_nocsrfcheck à 0 dans conf/conf.php

déconnectez vous - reconnectez vous de dolibarr -> vous avez encore le pb ?

Oui une autre instance.

Nickel pour la variable MAIN_FEATURES_LEVEL

Quel post 15x ?

La variable $dolibarr_nocsrfcheck est déjà à 0 dans conf/conf.php

Je peux confimé ce probleme avec « Security token has expired, so action has been canceled. »
Malheuruesement rien indique de que security token on parle. Mais je peux deja constater: Il a rien a voir avec MAIN_FEATURES_LEVEL ou MAIN_SECURITY_CSRF_WITH_TOKEN
On peut le mettre comme on veux ca change rien sur ce erreur
Je pense l’unique solution ici sera que le developpeur de ce message nous explique qu’il faut faire pour renouveler ce security token. Merci

Bonjour,

Pouvez-vous regarder les valeurs des variables :

  • $dolibarr_nocsrfcheck dans le fichier conf/conf.php ?
  • MAIN_SECURITY_CSRF_WITH_TOKEN dans Configuration-> Autre ?

Vous pouvez essayer de désactiver la sécurité en positionnant ces deux variables à :

  • $dolibarr_nocsrfcheck ⁼ 1
  • MAIN_SECURITY_CSRF_WITH_TOKEN = 0

Je confirme le problème sur 2 installations de dolibarr v13 que $dolibarr_nocsrfcheck soit à 0 ou à 1 dans conf/conf.php, cela ne change rien j’ai toujours le problème « Le jeton de sécurité a expiré, aussi l’action a été annulée. Merci de ré-essayer. »

  • $dolibarr_nocsrfcheck ⁼ 1
  • MAIN_SECURITY_CSRF_WITH_TOKEN = 0
    même problème
  • $dolibarr_nocsrfcheck ⁼ 0
  • MAIN_SECURITY_CSRF_WITH_TOKEN = 0
    même problème
  • $dolibarr_nocsrfcheck ⁼ 1
  • MAIN_SECURITY_CSRF_WITH_TOKEN = 1
    même problème

j’ai ce message uniquement dans la partie activation des modules uniquement dans la partie par exemple divers tout fonctionne.
Important j’utilise multicompany v12.01. Je suis passé en admin dans l’entité maitre et là ça marche . donc je souconne une incompatibilité avec multicompany v12.01 . Les autres conributeurs de ce forum qui rencontre c eproblème ont-ils également ce module installé?

En effet, j’ai aussi le module multi-compagnie sur celui qui est en erreur.

Pas sur le dolibarr qui n’a pas l’erreur.

Pour info, je réinstalle la 12.0.4, dans l’attente d’une solution.

Bonjour,
cela me semble le problème constant de l’adoption de modules externes sur Dolibarr :

  • quand on souhaite adopter la version suivante (majeure) de Dolibarr, il me semble qu’il est nécessaire de mettre en essai une installation hors production afin de faire le bilan des modules externes toujours fonctionnels et de ceux dont il faut solliciter ou attendre une mise à jour avant de basculer en production cette nouvelle version.
1 « J'aime »

Multicompany touche à la structure des entités. Une nouvelle version de multicompany en vue sans doute. Je vosi avec leur support

pour les autres modules c’est faisable. Pour multicompany, qui modifie la structure en créant des entités sosu dolibarr: ce n’est pas possible, sauf à avoir une autre installation de dolibarr sans multicompany (inutilisable dans la pratique) . Vivement que ce module fasse partie de dolibarr une bonne fois pour toute ( j’espère un jour).

$dolibarr_nocsrfcheck ⁼ 1
MAIN_SECURITY_CSRF_WITH_TOKEN = 0

toujours le problème malgré de paramétrage

Bonjour,

Le problème semble venir du module Multi Company.
Je vous conseil de rester en V12 tant que le développeur du module n’a pas fait les modifications nécessaires.

Un message a été scindé en un nouveau sujet : V13 Pb désactivation module [sans module multi-société]

Solution Provisoire à l’attente de la nouvelle màj :
J’ai remplacé le fichier modules.php sur le dossier admin avec le fichier modules.php de la version 12.0.4 et ça marche

J’ai remplacé le fichier modules.php sur le dossier dolibarr/htdocs/admin avec le fichier modules.php de la version 12.0.4 et ça marche

un bug dans modules.php v13 sans doute

Bonjour,
Vous pouvez également modifier le fichier /htdocs/admin/modules.php en attendant une correction. Commentez les ligne 31 à 33:

31 //if (!defined(‹ CSRFCHECK_WITH_TOKEN ›)) {
32 // define(‹ CSRFCHECK_WITH_TOKEN ›, ‹ 1 ›); // Force use of CSRF protection with tokens even for GET
33 //}

c’est un peu mettre un pansement sur une fracture:
il vaudrait mieux trouver pourquoi ça ne fonctionne pas chez eux (alors que ça fonctionne chez l’immense majorité), plutôt que supprimer un contrôle de sécurité.