Je suppose que c'est parce que vous utilisez PHP 7.1.0 (publié il y a quelques jours). D'après ce que je comprends, osticket 1.10 n'est toujours pas entièrement compatible avec 7.0. Vous voudrez peut-être baisser la note à 5,6 et voir si cela vous aide.

Merci! Je vais essayer de le réinstaller demain.
Tous ces trucs php sont nouveaux pour moi, alors je viens de télécharger une version à jour de tout. Je pense qu'il devrait y avoir une sorte de notification indiquant que php 7+ n'est pas encore officiellement pris en charge.

J'ai le même problème sur PHP 7.1, je vais rétrograder à PHP 5.6, tout fonctionne bien avec le plus ancien PHP.
Semble être un problème différent avec OsTicket et PHP 7 https://github.com/osTicket/osTicket/issues/3033

J'ai eu ce problème avec OSticket 1.10, Apache et PHP 7.1. Après avoir rétrogradé PHP à 7.0.14, l'erreur a disparu. J'espère que cela aide quelqu'un.

Est-ce qu'on y travaille ? PHP 7.1 est maintenant disponible et la prise en charge d'osTicket serait formidable.

J'espère que cela est en cours d'élaboration

J'ai le même problème sur PHP 7.1 + osticket 1.10.
Quelques informations sur mes fouilles :

• Quand je visite scp/login.php
  
  
  
  • Un Set-Cookie valide a été envoyé depuis l'osticket : "OSTSESSID=nntpjei4195nd6ru6h759mtk1d; expires=Tue, 28-Mar-2017 12:46:50 GMT; Max-Age=86400; path=%PATH%"
  
  
  • Mais l'enregistrement ost_session correspondant à cette clé (nntpje...) n'a pas été créé.
  
  
• Ensuite, lorsque je soumets le nom d'utilisateur et le mot de passe :
  
  
  
  • DoesNotExist exception dans upload/include/class.ostsession.php(184): QuerySet->one() (bien sûr, ceci est sauvé. )
  
  
• Lorsque je définis le backend de session sur memcache
  
  
  
  • La même erreur a été affichée.
  
  

Quelqu'un essaiera-t-il le patch ci-dessus 424bfc9 ? Cela a résolu mon problème.
Je déciderai de faire une pull request en fonction des retours.

@kaorukobo votre patch a fonctionné pour moi, en utilisant la dernière version d'osticket et le dernier php 7.1 de remi. Merci!

@kaorukobo

Peut confirmer que le correctif a fonctionné pour moi aussi. Centos 7, PHP 7.1.3 de Remi OSTicket 1.10

La demande de tirage correspondante a été approuvée :
https://github.com/osTicket/osTicket/pull/3773

Je viens d'installer le dernier osTicket, je suis sur PHP Version 7.1.5 sur Windows 7 Professional Edition Service Pack 1 i586, et j'ai obtenu le jeton CSRF valide requis lors de la première connexion à l'administrateur

C'est terrible. Même problème que https://github.com/osTicket/osTicket/issues/304 ? J'aurais aimé savoir avant la mise à niveau. Je ne peux pas revenir sur ce serveur car PHP7 est nécessaire pour certains de mes scripts. Cela devrait être la priorité 1.

Cher @ TomAshley303, il semble que ce problème avec PHP 7 ne soit pas résolu de sitôt, car garder PHP et les autres logiciels à jour est très important pour la sécurité. J'ai mis à niveau vers PHP 7
Voici le correctif qui fonctionne : https://github.com/osTicket/osTicket/commit/424bfc99d93b920f6162b602eeea41125086425d

Pour info, j'ai eu le même problème et l'heure était incorrecte sur ma machine.

Je viens de découvrir que la connexion sur mon OSticket est possible avec PHP5.6. Dès que j'ai configuré mon serveur sur PHP7.1, je ne peux plus me connecter à OSTicket et obtenir le message Valid CSRF Token Required.

@Richardvi osTicket prend en charge php7 et non php7.1. C'est donc probablement votre problème.

OK merci!

Merci mon frère ça m'aide vraiment.

Merci!!! Fonctionne bien :)

Nouveau sur osTicket aujourd'hui, briseur d'affaire pour moi s'il ne prend pas en charge php7.1.x, jusqu'à ce qu'il le fasse.

Fonctionne pour moi seulement besoin d'ajouter une nouvelle ligne sur un fichier 👍
https://github.com/osTicket/osTicket/commit/424bfc99d93b920f6162b602eeea41125086425d

Est-ce que quelqu'un sait si cela a été corrigé dans la dernière version 1.10.4 (hier) ?

Salut @ Je pense que ce problème n'est pas résolu, je n'ai jamais testé la dernière version telle qu'elle a été publiée récemment.
Vous pouvez lire sur la note de publication ce que la mise à jour comprend : https://github.com/osTicket/osTicket/commit/035fd0af32647199bae662eda6517f70e9225329

@PeopleInside

C'est quelque peu abordé dans v1.11.0rc-1 avec ce fichier . Au lieu de vous donner une fenêtre vide avec un message d'erreur, il vous donne la page de connexion avec l'erreur "Valid CSRF Token".

À votre santé.

Windows + Apache + PHP Version 7.2.7

session.auto_start=1 a fonctionné pour moi

Ubuntu 18.04 x64 + Apache2 + PHP 7.2-10 + osT 1.10.4

/etc/php/7.2/apache2/php.ini session.auto_start=1 a fonctionné pour moi aussi.

/etc/php/7.2/apache2/php.ini session.auto_start=1 a fonctionné pour moi aussi.

Salut @jpkh merci beaucoup pour le partage où session.auto_start=1 devrait être placé. Ceci est une modification de la configuration php (ini), je demande ce qu'OsTicket devrait changer pour résoudre ce problème. Habituellement, je préfère faire un correctif dans le logiciel et non sur le PHP. C'est bien de savoir qu'il existe une solution pour travailler avec PHP 7.2, mais j'attendrai peut-être de comprendre si le problème peut être résolu du côté d'OsTicket.

La dernière version est compatible avec Php 7.0, vous pouvez donc passer de 7.1 à 7.0. Correction facile

Dans PHP 7.1 et versions ultérieures, vous devez renvoyer une chaîne à partir d'un gestionnaire de lecture de session ou vous obtiendrez une erreur - la documentation a toujours dit qu'elle devrait renvoyer une chaîne, mais PHP ne fait que commencer à l'appliquer. Regardez dans les journaux php pour voir si vous avez PHP Avertissement : session_start() : Échec de la lecture des données de session : utilisateur

en ajoutant la ligne suivante JUSTE avant le retour dans la méthode read dans class.ostsession.php

if(!is_string($this->data->session_data)) {
    $this->data->session_data = strval($this->data->session_data);
}

Cela garantit que peu importe ce que vous mettez dans les données de session, vous retournez toujours une chaîne comme vous le devriez

Déclasser votre version PHP n'est jamais une bonne idée pour des raisons de sécurité. Doublement mauvais car PHP 7.0 est déjà hors du support régulier et est hors du support de sécurité dans un mois :(

http://php.net/supported-versions.php

@auroraeosrose il y a deux fonctions de lecture dans class.ostsession.php pourriez-vous spécifier la ligne sur laquelle cet extrait doit être inséré ? la fonction de lecture à la ligne 270 ? ou celui sur 183 ? PS merci pour cette solution... Lorsque j'ai utilisé session.auto_start=1 cela a cassé l'une des autres applications (TestLink) que j'exécute sur le même serveur, j'apprécie donc une solution qui n'implique que des modifications de l'OST et non du php .ini

@davidtessier

Celui de la classe DbSessionBackend , placez-le juste au-dessus du retour.

PS
Ceci est abordé dans 1.11 avec :

3955

4344

À votre santé.

Merci! Ça a marché.

Dans PHP 7.1 et versions ultérieures, vous devez renvoyer une chaîne à partir d'un gestionnaire de lecture de session ou vous obtiendrez une erreur - la documentation a toujours dit qu'elle devrait renvoyer une chaîne, mais PHP ne fait que commencer à l'appliquer. Regardez dans les journaux php pour voir si vous avez PHP Avertissement : session_start() : Échec de la lecture des données de session : utilisateur

en ajoutant la ligne suivante JUSTE avant le retour dans la méthode read dans class.ostsession.php

if(!is_string($this->data->session_data)) {
    $this->data->session_data = strval($this->data->session_data);
}

Cela garantit que peu importe ce que vous mettez dans les données de session, vous retournez toujours une chaîne comme vous le devriez

Déclasser votre version PHP n'est jamais une bonne idée pour des raisons de sécurité. Doublement mauvais car PHP 7.0 est déjà hors du support régulier et est hors du support de sécurité dans un mois :(

http://php.net/supported-versions.php

Merci, cela fonctionne pour moi.

La solution de @auroraeosrose a également fonctionné pour moi sur PHP7.2.15 et osticket 1.10.5

La solution de @auroraeosrose fonctionne sur :

ID du distributeur : Debian
Description : Debian GNU/Linux 9.8 (extension)
Version : 9.8
Nom de code : étirer
Apache 2.4
PHP version 7.2.16