Tickets non créés pour profils post-only suite installation 10.0.12

JeanBart · 2024-02-02 12:56:33

Bonjour,
nous avons installé la semaine dernière la dernière version GLPI 10.0.11, qui fonctionnait parfaitement.
Suite à une alerte de sécurité, nous sommes montés hier soir en 10.0.12.
Nous venons de constater que, depuis, nos utilisateurs ne peuvent créer de ticket.
Depuis l'interface simplifiée, l'utilisateur post-only (LDAP) crée un ticket, mais l'élément n'est pas enregistré, sans qu'aucun message d'erreur ne soit généré. Pas de trace d'un problème dans les logs, et l'utilisateur est persuadé d'avoir déposé un ticket!
Un utilisateur admin arrive au contraire à enregistrer un ticket.
La seule cause évidente nous semble être cette montée de version. D'autant plus que le change log indique :
"Injection LDAP pendant l’authentification (CVE-2023-51446)"

Sommes nous les seuls à avoir rencontré le problème? Une solution existe-t-elle?

Merci

cconard96 · 2024-02-02 13:33:09

Bonjour,

Pouvez-vous tester ce patch ?
https://github.com/glpi-project/glpi/pull/16496

JeanBart · 2024-02-02 14:09:00

Merci pour votre retour.
Le patch est installé mais nous n'avons pas constaté d'amélioration

cconard96 · 2024-02-02 15:08:41

Il n'y a rien dans les journaux du dossier files/_log ?

Toyama · 2024-02-02 16:17:59

je suis rassurer de voir que je ne suis pas le seul
j'ai le même problème plus aucun utilisateur ne peut crée des tickets
même pas le compte administrateur

j'ai réussi a prendre une image d'une erreur qui passe en un fraction de seconde
erreur php

et lorsque je valide le ticket la partie description fait un gros carrer blanc (le temps que la page charge , c'est aussi tres rapide)

erreur

j'ai l'impression que c'est un ticket que j'ai recus l'ors de la mise a jour de la base de donnée non ?

voici les log present dans files/_log

access-errors.log
bench_inventory.log
cron.log
event.log
migration_to_1.21.6.log
migration_to_1.4.3.log
migration_to_2.12.2.log
migration_to_2.13.8.log
migration_to_2.4.0.log
migration_to_2.5.0.log
migration_to_2.5.2.log
migration_to_2.7.0.log
php-errors.log
sql-errors.log
warning_during_migration_to_2.11.7.log

Last edited by Toyama (2024-02-02 16:24:29)

JeanBart · 2024-02-02 18:00:05

Nous venons de désactiver les SLAs TTO et TTR, le problème n'apparait plus. Dans l'attente, c'est une solution

nessgo · 2024-02-03 05:51:54

Bonjour je confirme que cela fonctionne en desactivant les SLAs TTO et TTR.

pour repondre à @cconard96 le patch GLPI "16496" ne fontionne pas chez moi

Hello I confirm that it works by disabling the TTO and TTR SLAs.

to answer @cconard96 the patch GLPI "16496" doesn't work for me

Last edited by nessgo (2024-02-03 05:54:25)

cconard96 · 2024-02-03 13:55:24

OK, je pense avoir trouvé le vrai problème.

Vous pouvez voir mes commentaires sur le PR, mais au-dessus des lignes qu'ils avaient suggéré de changer auparavant, il y a une partie avec "??". Il doit s'agir de "?:".

L'explication technique est que GLPI initialise chaque champ comme un texte vide "". Le "??" L'opérateur est un raccourci qui indique d'utiliser la valeur de gauche si elle est définie et non nulle, sinon d'utiliser la valeur de droite. "?:" signifie utiliser la valeur de gauche si elle est "véridique". Une chaîne vide est utilisée dans le code d'origine lorsque nous attendons un nombre réel pour la partie suivante, tandis que "?:" lui fait utiliser la valeur par défaut de 0 comme nous le souhaitons.

nessgo · 2024-02-03 14:48:23

Bonjour @cconard96

je vous confirme que cela fonctionne maintenant avec les modifications que vous avez fait dans le fichier Ticket.php

Ligne 448: $data['sla_waiting_duration'] = $this->fields['sla_waiting_duration'] ?? 0;
Ligne 493: $data['ola_waiting_duration'] = $this->fields['ola_waiting_duration'] ?? 0;

A remplacer

Ligne 448: $data['sla_waiting_duration'] = $this->fields['sla_waiting_duration'] ?: 0;
Ligne 493: $data['ola_waiting_duration'] = $this->fields['ola_waiting_duration'] ?: 0;

Un grand Merci ! @cconard96

Last edited by nessgo (2024-02-03 14:48:41)

JeanBart · 2024-02-07 11:04:31

Bonjour,
les modifications apportées ont résolu le problème de création des tickets par nos agents post-only.
Il reste toutefois une difficulté. Nous utilisons le plugin MetaDemands et depuis la semaine dernière, nos agents (post only) n'ont plus accès aux formulaires prévus. L'interface simplifiée n'est plus remplacée par un formulaire meta demands. Cela fonctionne bien avec les niveaux admin. Aviez vous identifié cette difficulté?
Merci

JeanBart · 2024-02-12 21:03:44

Bonjour,
personne n'a rencontré le problème?
Le comportement est comme si l'option du plugin metademands "Activer la transformation d'un ticket en méta-demande" était désactivée

Forum GLPI-Project

Announcement

#1 2024-02-02 12:56:33

Tickets non créés pour profils post-only suite installation 10.0.12

#2 2024-02-02 13:33:09

Re: Tickets non créés pour profils post-only suite installation 10.0.12

#3 2024-02-02 14:09:00

Re: Tickets non créés pour profils post-only suite installation 10.0.12

#4 2024-02-02 15:08:41

Re: Tickets non créés pour profils post-only suite installation 10.0.12

#5 2024-02-02 16:17:59

Re: Tickets non créés pour profils post-only suite installation 10.0.12

#6 2024-02-02 18:00:05

Re: Tickets non créés pour profils post-only suite installation 10.0.12

#7 2024-02-03 05:51:54

Re: Tickets non créés pour profils post-only suite installation 10.0.12

#8 2024-02-03 13:55:24

Re: Tickets non créés pour profils post-only suite installation 10.0.12

#9 2024-02-03 14:48:23

Re: Tickets non créés pour profils post-only suite installation 10.0.12

#10 2024-02-07 11:04:31

Re: Tickets non créés pour profils post-only suite installation 10.0.12

#11 2024-02-12 21:03:44

Re: Tickets non créés pour profils post-only suite installation 10.0.12

Board footer