You are not logged in.
Pages: 1
Bonjour,
On n'arrive pas à migrer notre GLPI de la v10.0.8 à 10.0.10. J'ai l'impression qu'il y a un problème pendant les script de MAJ... Après investigation, j'ai désactivé l'option "zend_extension=opcache" dans notre php.ini et l'upgrade fonctionne. Si je vais plus loin, une fois en 10.0.10, en laissant l'option désactivé, je me connecte à glpi sans problème (connexion AD); si je réactive l'option, je ne peux plus me connecter! J'ai une erreur "L'action que vous avez réalisée n'est pas autorisée."
J'ai trouvé un problème similaire au notre : https://github.com/glpi-project/glpi/issues/15132 .
Seulement je ne comprends pas ce qu'il faut faire dans le post de cconard96 :
The reason I asked was because there could be a cache conflict. On Windows (and only Windows), all processes running the same Server API (SAPI), in this case apache2handler, under the same user account share the same OPCache instance.
You can add "opcache.cache_id=${OPCACHE_ID}" to your PHP configuration and then set a unique value to that environment variable in your Apache virtual host config(s) (using SetEnv) to have them use separate caches.
This setting only exists for Windows.
GLPI 10.0.7
Apache 2.4.55
PHP Version 8.1.16
MySQLi 8.1.16
Offline
Bonjour,
Mes suggestions étaient d'ajouter une ligne au fichier de configuration "php.ini" pour attribuer des ID de cache uniques basés sur une variable d'environnement définie pour chaque vHost Apache.
Cela n'existe qu'en tant que paramètre sous Windows. De plus, si plusieurs instances GLPI ne s'exécutent pas en même temps, cela peut n'être qu'une solution de contournement plutôt qu'une solution appropriée.
En résumé:
1. Ajoutez la ligne opcache.cache_id à votre fichier php.ini (recherchez l'emplacement du fichier pour votre plateforme si vous ne le connaissez pas)
2. Modifiez la configuration Apache vHost pour la ou les instances GLPI et ajoutez "SetEnv OPCACHE_ID my_glpi", où "my_glpi" est un identifiant unique de votre choix pour cette instance, à l'intérieur de l'élément <VirtualHost>. Encore une fois, recherchez l'emplacement des fichiers de configuration du site pour votre plate-forme si vous ne le savez pas.
3. Redémarrez Apache pour que les modifications prennent effet.
Idéalement, chaque site devrait avoir son propre vHost. Si vous n'exécutez qu'un seul site, vous pouvez utiliser la configuration par défaut. Si vous exécutez plusieurs instances GLPI, elles doivent chacune avoir leur propre configuration.
GLPI Collaborator and Plugin Developer.
My non-English comments are automated translations. Sorry for any confusion that causes.
Mes commentaires non anglais sont des traductions automatiques. Désolé pour toute confusion qui cause.
Mis comentarios que no están en inglés son traducciones automáticas. Perdón por cualquier confusión que cause.
Offline
Bonjour,
Merci de ta réponse!
Si j'ai bien compris, j'ai ajouté :
opcache.cache_id=1
dans php.ini et
<VirtualHost 192.168.3.104>
DocumentRoot "F:/www"
ServerName lab-intranet04
ServerAlias server
SetEnv OPCACHE_ID 1
</VirtualHost>
dans http.conf
j'ai saisi? Je suis pas sur pour l'ID! J'ai mis 1... je n'ai qu'un seul site et qu'une seul instance de GLPI.
GLPI 10.0.7
Apache 2.4.55
PHP Version 8.1.16
MySQLi 8.1.16
Offline
Bonjour,
Cela devrait être exactement :
opcache.cache _id="${OPCACHE _ID}"
Vous spécifiez l'ID réel dans chaque configuration vHost comme vous l'avez déjà fait. L'identifiant peut être n'importe quoi.
Si vous n’avez qu’un seul site, il ne s’agit probablement que d’une solution de contournement. Je ne sais pas pourquoi les gens signalent soudainement des problèmes d'opcache après la ou les deux dernières versions.
GLPI Collaborator and Plugin Developer.
My non-English comments are automated translations. Sorry for any confusion that causes.
Mes commentaires non anglais sont des traductions automatiques. Désolé pour toute confusion qui cause.
Mis comentarios que no están en inglés son traducciones automáticas. Perdón por cualquier confusión que cause.
Offline
Ok merci de ta réponse! Malheureusement pour nous, cela n'a pas résolu le problème : j'ai toujours
CSRF check failed for User ID: at /glpi/front/login.php2023-10-31 15:25:29 [@LAB-INTRANET04]
dans le access.log
GLPI 10.0.7
Apache 2.4.55
PHP Version 8.1.16
MySQLi 8.1.16
Offline
Pouvez-vous essayer d'activer l'option PHP "opcache.blacklist_filename" et de définir la valeur du chemin d'accès à un fichier texte contenant le chemin complet du fichier Session.php dans GLPI (le chemin relatif est src/Session.php) ?
Après le redémarrage d'Apache, cela devrait empêcher OPCache de faire quoi que ce soit avec ce fichier et pourrait identifier s'il y a un problème avec celui-ci.
GLPI Collaborator and Plugin Developer.
My non-English comments are automated translations. Sorry for any confusion that causes.
Mes commentaires non anglais sont des traductions automatiques. Désolé pour toute confusion qui cause.
Mis comentarios que no están en inglés son traducciones automáticas. Perdón por cualquier confusión que cause.
Offline
Bonjour,
Au final, il n'y a pas de solution? Si on passe à GLPI 10.0.10 pour corriger la faille de sécurité, nous devons désactiver opcache quitte à dégrader les performances de GLPI?
Doit-on créer un bogue sur Git?
GLPI 10.0.7
Apache 2.4.55
PHP Version 8.1.16
MySQLi 8.1.16
Offline
Bonjour,
Il y a une discussion ici :
https://github.com/glpi-project/glpi/issues/15899
Je n'ai pas encore eu le temps de le faire, mais il a été suggéré de tester la dernière version de PHP 8.1 pour voir s'il s'agit d'un bug dans PHP lui-même.
GLPI Collaborator and Plugin Developer.
My non-English comments are automated translations. Sorry for any confusion that causes.
Mes commentaires non anglais sont des traductions automatiques. Désolé pour toute confusion qui cause.
Mis comentarios que no están en inglés son traducciones automáticas. Perdón por cualquier confusión que cause.
Offline
Bonjour et merci de ton retour. Je suis passé en php 8.2.12 mais sans succès : toujours le même message :
L'action que vous avez réalisée n'est pas autorisée.
et dans l'access-errors.log :
CSRF check failed for User ID: at /glpi/front/login.php2023-11-07 10:05:27 [@LAB-INTRANET04]
CSRF check failed for User ID: at /glpi/front/login.php2023-11-07 10:06:04 [@LAB-INTRANET04]
CSRF check failed for User ID: at /glpi/front/login.php
GLPI 10.0.7
Apache 2.4.55
PHP Version 8.1.16
MySQLi 8.1.16
Offline
Bonjour,
6 mois exactement que j'ai désactiver OPcache, je souhaiterais bien-entendu le réactiver pour les gains de performance.
Ma question: avons-nous trouver une solution depuis ?
Petit rappel: cela concerne les systèmes Windows, avec un site GLPI émulé sur XAMPP. La mise a jour avec OPcache d'activer empêcher les login à GLPI
Je vous remercie d'avance.
BPLC
Offline
Bonjour,
Pour information, j'utilise IIS (Windows Server donc) et héberge plusieurs sites GLPI dont certains sont en SSL et d'autres pas. J'ai eu le problème de connexion impossible lorsque le site n'était pas en SSL. Cela provient du fait que la variable 'session.cookie_secure' est à 'on', ce qui est correct pour les sites avec SSL.
Pour qu'un site fonctionne sans SSL, j'ai ajouté une section :
[PATH=D:/chemin_mon_site_sans_ssl]
session.cookie_secure = off
Cela permet de faire fonctionner un site de test, par exemple, pour lequel on a pas de certificat et cela permet de conserver la valeur par défaut (dans la section [session]) correcte pour les sites avec certificat.
Ceci étant, bien sur, valable pour des sites intranet...
Cordialement,
GLPI : 10.0.16
OS : RH9 + Apache
php : 8.3.11,
MariaDB : 10.11.9
Offline
Pages: 1