Problème balises dans traitement du ticket

lenainjaune · 2021-07-31 12:40:41

Bonjour tout le monde

D'abord un ÉNORME merci pour cet outil et pour le temps et l'énergie qu'on passé ses contributrices et contributeurs ; ça fait des années que je l'utilise et j'en suis pleinement satisfait.

Je viens avec un problème et je ne sais pas si c'est un bug réel, une mauvaise utilisation du logiciel ou si le problème n'existe plus avec les versions ultérieures (celle actuelle : glpi 9.4.3 sous Linux - voir plus bas les infos du bug).

Quand j'édite des actions sur un ticket dans l'assistance, j'ai pris l'habitude de coller le code qui m'a permis de résoudre un problème ou d'exécuter une tâche (essentiellement en bash sous Linux), pour le conserver et vite pouvoir le réutiliser. Seulement voilà, quand je colle du code qui contient des balises (html, xml, etc.) et que je valide l'édition, dans l'historique des actions, je vois le code tel que je l'ai copié. Si je modifie l'action, le code disparait (aucun message n'indique que le contenu a été tronquée) ... et comme bien souvent le code est noyé dans un ensemble de texte, quand je valide à nouveau cette fois je perds définitivement le-dit code (et donc le temps que j'ai passé à trouver cette solution). J'ai également essayé de formater en code ou pre mais j'ai l'impression que ça ne change rien.

C'est problématique car une partie de mon travail risque d'être réduit à néant, dès lors que je modifierais une action sans avoir en tête ce comportement erratique.

Est-ce la méthode à employer pour conserver son code intact ?

Est-ce normal qu'il n'y ait pas de message pour avertir de la troncation ?

Avec adelphité
lnj

---

Les infos de bug :
installation manuelle par TARBALL sous Debian Stretch + mariadb + lighttpd + php7 :

GLPI 9.4.3 (/glpi => /var/www/html/glpi)
Installation mode: TARBALL
    
Operating system: Linux glpi-test 4.9.0-12-amd64 #1 SMP Debian 4.9.210-1 (2020-01-20) x86_64
PHP 7.0.33-0+deb9u7 fpm-fcgi (Core, PDO, Phar, Reflection, SPL, SimpleXML, Zend OPcache, apc, apcu, calendar, cgi-fcgi, ctype,
	curl, date, dom, exif, fileinfo, filter, ftp, gd, gettext, hash, iconv, imap, json, ldap, libxml, mbstring, mysqli, mysqlnd,
	openssl, pcre, pdo_mysql, pdo_pgsql, pdo_sqlite, pgsql, posix, readline, session, shmop, sockets, sqlite3, standard, sysvmsg,
	sysvsem, sysvshm, tokenizer, wddx, xml, xmlreader, xmlrpc, xmlwriter, xsl, zlib)
Setup: max_execution_time="30" memory_limit="128M" post_max_size="20M" safe_mode="" session.save_handler="files"
	upload_max_filesize="20M" 
Software: lighttpd/1.4.45
	Mozilla/5.0 (X11; Linux x86_64; rv:90.0) Gecko/20100101 Firefox/90.0
Server Software: Debian 9.12
	Server Version: 10.1.45-MariaDB-0+deb9u1
	Server SQL Mode: 
	Parameters: glpiuser@localhost/glpidb
	Host info: Localhost via UNIX socket
	
mysqli extension is installed
ctype extension is installed
fileinfo extension is installed
json extension is installed
mbstring extension is installed
iconv extension is installed
zlib extension is installed
curl extension is installed
gd extension is installed
simplexml extension is installed
xml extension is installed
ldap extension is installed
imap extension is installed
Zend OPcache extension is installed
APCu extension is installed
xmlrpc extension is installed
CAS extension is installed
exif extension is installed
Database version seems correct (10.1.45) - Perfect!Database version seems correct (10.1.45) - Perfect!
OK/var/www/html/glpi/files/_log : OK
OK/var/www/html/glpi/config : OK
OK/var/www/html/glpi/files : OK
OK/var/www/html/glpi/files/_dumps : OK
OK/var/www/html/glpi/files/_sessions : OK
OK/var/www/html/glpi/files/_cron : OK
OK/var/www/html/glpi/files/_graphs : OK
OK/var/www/html/glpi/files/_lock : OK
OK/var/www/html/glpi/files/_plugins : OK
OK/var/www/html/glpi/files/_tmp : OK
OK/var/www/html/glpi/files/_cache : OK
OK/var/www/html/glpi/files/_rss : OK
OK/var/www/html/glpi/files/_uploads : OK
OK/var/www/html/glpi/files/_pictures : OK
Web access to the files directory should not be allowed but this cannot be checked automatically on this instance.
Make sure acces to error log file is forbidden; otherwise review .htaccess file and web server configuration.OK
SELinux mode is Disabled

* Les informations obtenues en mode debug :

J'ai activé le debug et debbugé SQL (tail -f GLPI/files/_log/sql-errors.log) et PHP (tail -f GLPI/files/_log/php-errors.log) pendant la création d'un ticket avec un code à balise
=> rien remonté

* Navigateur utilisé (IE, Moz...) et version.

Firefox (ici v90.0.2 64 bits)

Last edited by lenainjaune (2021-07-31 17:28:48)

lenainjaune · 2021-08-03 01:45:18

Pour le moment j'ai trouvé une solution de contournement, mais comme je l'ai dit, cela suppose d'y penser à chaque fois.

Rappel : si je ne protège pas, sur GLPI à la prochaine édition le code sera revenu avec les balises <...> et à la suivante tout aura disparu !

Supposons que dans un script bash, je créée dynamiquement un fichier de configuration XML de périphérique USB identifié par son ID vendor et ID product, pour l'attacher à une machine virtuelle (ici QEmu/KVM) :

<hostdev mode='subsystem' type='usb' managed='yes'>
 <source>
  <vendor id='0x$vendor'/>
  <product id='0x$product'/>
 </source>
</hostdev>

Pour protéger le code je convertis "à ma sauce" les balises XML :
<XXX -> < XXX ainsi plus de format de balise
et j'effectue le procédé inverse quand j'utilise ce code.

Donc pour créer le code protégé :

user@host:~$ ( cat << 'EOF'
<hostdev mode='subsystem' type='usb' managed='yes'>
 <source>
  <vendor id='0x$vendor'/>
  <product id='0x$product'/>
 </source>
</hostdev>
EOF
) | sed 's/</< /g'

=>

< hostdev mode='subsystem' type='usb' managed='yes'>
< source>
< vendor id='0x$vendor'/>
< product id='0x$product'/>
< /source>
< /hostdev>

=> il reste toujours lisible bien qu'inexploitable en l'état

Rappel : dans un heredoc 'EOF' conserve le texte tel quel (pas d'expansion de variable)

Pour conserver le code dans un suivi il faut simplement afficher le code protégé et le mécanisme pour décoder sous sa forme originelle :

user@host:~$ ( cat << 'EOF'
< hostdev mode='subsystem' type='usb' managed='yes'>
 < source>
  < vendor id='0x$vendor'/>
  < product id='0x$product'/>
 < /source>
< /hostdev>
EOF
) | sed 's/< /</g'

=> qui donne la forme originelle :

Et vous, une autre solution ?

Last edited by lenainjaune (2021-09-17 02:01:42)

lenainjaune · 2021-08-27 23:02:53

Je suis réellement étonné et très triste . Presque un mois depuis l'ouverture du fil et pas une réponse...

Je suis toujours en recherche d'une solution.

lenainjaune · 2021-08-28 10:50:27

Je croyais que cette rubrique était réservée aux bogues. Je me contente de remonter un dysfonctionnement et suis en attente d'une solution de contournement autre que la mienne qui est un peu lourde et surtout peu lisible ...

lenainjaune · 2021-09-17 00:45:17

Comme je suis tout seul sur ce fil, je vais profiter de cet espace disque laissé gracieusement sur les serveurs du forum, pour conserver mon travail :

Autre approche (super on ne peut PAS mettre de lien pour indiquer les sources ; à malin, malin et 1/2)

avec perl -MHTML::Entities -pe 'encode_entities($_,"<>");' pour encoder et perl -MHTML::Entities -pe 'decode_entities($_);'

Pour info : on peut limiter les encodages entités à < et >

basé sur :
h t t p s : / / s t a c k o v e r f l o w . c o m / a / 1 3 1 6 1 7 1 9
h t t p s : / / p e r l . m i n e s - a l b i . f r / p e r l 5 . 6 . 1 / s i t e _ p e r l / 5 . 6 . 1 / s u n 4 - s o l a r i s / H T M L / E n t i t i e s . h t m l

Last edited by lenainjaune (2021-09-17 02:06:00)

LaDenrée · 2021-09-17 09:35:06

votre post a été lu mais parfois personne n'a de réponse. une réponse du type "je ne sais pas" n'aurai pas plus d'intérêt.

j'avais eu le même problème dans les descriptions ( https://github.com/glpi-project/glpi/issues/140) il semble que ce soit résolu depuis peu.
peut être que ce sera aussi résolu dans les tâches.

lenainjaune · 2021-09-17 09:47:47

Ah enfin un être vivant (sensation lourde de se sentir seul, même dans un espace virtuel... ), et en plus pas par n'importe qui, c'est "la denrée" GLOUGLOUGLOUGLOULOU

Ok ! Effectivement une réponse "je ne sais pas" n'apporte pas grand chose...

Mais j'imaginais ne pas être le seul à avoir ce type de besoin et donc je supposais que d'autres personnes avaient trouvé une solution de contournement plus pratique.

En tout cas merci pour le retour

Forum GLPI-Project

Announcement

#1 2021-07-31 12:40:41

Problème balises dans traitement du ticket

#2 2021-08-03 01:45:18

Re: Problème balises dans traitement du ticket

#3 2021-08-27 23:02:53

Re: Problème balises dans traitement du ticket

#4 2021-08-28 10:50:27

Re: Problème balises dans traitement du ticket

#5 2021-09-17 00:45:17

Re: Problème balises dans traitement du ticket

#6 2021-09-17 09:35:06

Re: Problème balises dans traitement du ticket

#7 2021-09-17 09:47:47

Re: Problème balises dans traitement du ticket

Board footer