bug of entity completename

[yllen]

Code of Conduct

• I agree to follow this project's Code of Conduct

Is there an existing issue for this?

• I have searched the existing issues

Version

9.5.6 - 9.5.7dev

Bug description

this commit 58c9a40#diff-ff7482b70ea2df3946d8473cc34ffc57b3c254a4f47bea852e93688b455c8bc6 in dbutils.class introduce an error when you used getDorpdownName function for an entity.
Issue visible for my PDF plugin but also for all plugins using this function
With this commit

without this commit

Relevant log output

No response

Page URL

all PDF pages

Steps To reproduce

No response

Your GLPI setup information

No response

Anything else?

No response

[cedric-anne]

Hi,

This has been done to ensure that returned value is html encoded correctly. Before this fix, if you had a < or a > in an entity name, method result was containing both encoded and non encoded html special chars.

For instance, with this entity tree

Root
  ↳entity <test>
    ↳sub entity

result was Root > entity &lt:test> > sub entity
ans is now Root > entity &lt:test> > sub entity.

In GLPI, all data retrieved from database is expected to be protected against XSS, and the new behaviour conforms to this rule.

In your PDF plugin, you are using Html::clean() on all Dropdown::getDropdownName() calls, except for the one related to entity name. Maybe you should use Html::clean() on this one too.

[yllen]

tests are already done this Html:clean, and same result

$entity = Html::clean(Dropdown::getDropdownName('glpi_entities', $this->obj->getEntityID()));`

      //     $entity = ' ('.Dropdown::getDropdownName('glpi_entities', $this->obj->getEntityID()).')';
        }
        $this->pdf->setHeader(sprintf(__('%1$s - %2$s'), $this->obj->getTypeName(),
                                      sprintf(__('%1$s (%2$s)'), $name, $entity)));

`

[cedric-anne]

Hi @yllen ,

I made some tests and this "encoding" issue will also appear if the exported item contains a > or a < in its name, so fix have to be more global on PDF plugin side. I proposed a PR: yllen/pdf#9

I close this issue as the behaviour explained in my previous comment seems correct, so we will not revert this change.

Regards