You are not logged in.
Pages: 1
Topic closed
Bonjour,
j'ai un petit problème : j'ai copié ma version 0.83.7 pour tester la migration vers la 0.85.2.
Problème :
L'action que vous avez demandée n'est pas autorisée. Recharger la page précédente avant de faire une action à nouveau.
Et ce, que j'utilise l'user glpi, l'user prof/demo, ou l'user que j'avais lié à mon AD.
Quelqu'un a une idée ?
No slave DB
GLPI_DB_OK
GLPI_SESSION_DIR_OK
Check LDAP servers: Connexion AD_OK
No IMAP server
No CAS server
No mail collectorGLPI_OK
- SoluTek.fr - | occasional plugin contributor
GLPI 9.3.1
Windows 2016 - IIS Reverse Proxy - HTTPS/Let's Encrypt | Apache 2.4.33 / PHP 7.1.16
Offline
J'ai même essayé de changer le mdp comme indiqué ici : http://www.glpi-project.org/forum/viewt … 84#p188084
Mais ça ne change rien...
- SoluTek.fr - | occasional plugin contributor
GLPI 9.3.1
Windows 2016 - IIS Reverse Proxy - HTTPS/Let's Encrypt | Apache 2.4.33 / PHP 7.1.16
Offline
Bon je continue de me débrouiller seul.
J'ai trouvé ce post : http://www.glpi-project.org/forum/viewt … 37#p165537
Ca corrige le problème, sauf que dans la 0.85.2 c'est à la ligne 171.
Mais maintenant j'ai
Utilisation invalide de l'identifiant de session
- SoluTek.fr - | occasional plugin contributor
GLPI 9.3.1
Windows 2016 - IIS Reverse Proxy - HTTPS/Let's Encrypt | Apache 2.4.33 / PHP 7.1.16
Offline
Bon, j'ai voulu refaire une installation propre : plus moyen d'installer !
L'action que vous avez demandée n'est pas autorisée. Recharger la page précédente avant de faire une action à nouveau.
Une solution ?
- SoluTek.fr - | occasional plugin contributor
GLPI 9.3.1
Windows 2016 - IIS Reverse Proxy - HTTPS/Let's Encrypt | Apache 2.4.33 / PHP 7.1.16
Offline
Il y a eu un mécanisme de sécurité de mis en 0.83.91.
Donc vous ne pouvez plus revenir en arrière et relancer l'action.
Lorsque vous avez besoin de faire un retour arrière dans votre navigateur, il faut impérativement recharger la page avant de refaire votre action.
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Il ne s'agissait pas de revenir en arrière, mais bien d'un accès direct à la racine du site, après un nouvel upload d'une archive vierge.
Donc ça n'aurait pas du arriver.
Par contre je viens de m'apercevoir d'une chose : j'ai un vhost (nginx) avec 2 server_name : glpi.dev.domaine et glpi.dev.intra.domaine.
Quand je veux me connecter depuis dev.intra ça me sort "identifiant de session incorrect".
Par contre, de l'extérieur, ça marche sans problème ! Il y aurait donc un contrôle qui se base sur quelque chose qui n'est pas correct, car j'ai bien défini l'url d'accès dans la conf à dev.intra.
- SoluTek.fr - | occasional plugin contributor
GLPI 9.3.1
Windows 2016 - IIS Reverse Proxy - HTTPS/Let's Encrypt | Apache 2.4.33 / PHP 7.1.16
Offline
up !
- SoluTek.fr - | occasional plugin contributor
GLPI 9.3.1
Windows 2016 - IIS Reverse Proxy - HTTPS/Let's Encrypt | Apache 2.4.33 / PHP 7.1.16
Offline
Bon je reviens vers vous concernant ce problème.
J'ai trouvé LA cause ! C'est nginx ! En fait, quand il est utilisé en tant que serveur web et pas reverse proxy, il y a un petit bug sur le server_name. Il prend pas le bon de temps en temps. Du coup pas de correspondance entre le sous domaine que j'annonce et celui que lui attend > erreur.
Du coup il faut faire deux vhosts ! et ça passe
- SoluTek.fr - | occasional plugin contributor
GLPI 9.3.1
Windows 2016 - IIS Reverse Proxy - HTTPS/Let's Encrypt | Apache 2.4.33 / PHP 7.1.16
Offline
Merci du retour. Je clos ce post.
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Pages: 1
Topic closed