Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion

osTicket v1.10 (stable) and Maintenance Release v1.9.15 are now available! Go get it now

Guillemets lead to imcomplete text parts

Hi there,

today I wrote a ticket comment containing a guillemet (writing "<= 15 minutes…").

Though the editor escaped it correctly into a &lt;, some parsing mechanism interpretes the glyph as an opening tag and snips the rest of the line before saving it.

Turning off HTML in osTicket solves this issue, but that's not an option.

Is there any solution to this?

Best regards,


  • Please help us to help you by reading and following the posting guidelines located in this thread: Please read before requesting assistance.  The more information you give us the better we will be able to assist you. Thank you.

    guillemets (aka &lt; &gt;) are HTML reserved characters.  The third party text editor (It's called Redactor) sounds like it isn't handling them properly.  You can try using the source view and entering them that way, or shutting of HTML.

    I'll ping the devs to take a look at this but I dont think that this is an osTicket issue per se, and is a Redactor issue.
  • edited December 2017

    I believe @ntozier is correct in that this is more of a Redactor issue. You can look into how Redactor cleans the tags and such via js/redactor.min.js, js/redactor-plugins.js, and js/redactor-osticket.js. You can add allowed tags to Redactor so that it will leave them alone when parsing. After adding the tag to the allowed tags, see if they are working how you wan them to. If they are working correctly but still stripping everything after then you need to look into how we parse the response body via include/class.format.php -> function sanitize()

    Please Note:
    This task is VERY dangerous as you might be opening yourself/company/users to XSS...which is pretty serious and no fun at all lol

    I hope this helps! Cheers.
  • Hi ntozier,
    I checked the source view before I opened this ticket. Like expected, HTML specialchars are treated properly.
    Inspecting the sent POST request I see properly encoded HTML aswell:
    But the database entry contains only:
     <br /><br />Sos so so so<br /><br /><br /><br /> 
    This looks very much as if the sanitizer of osTicket did the deed, not Redactor.

    I'll hava a look into the function KevinTheJedi mentioned, maybe I can contribute a solution.

  • Ok, looks like the reason is in the safe_html function resp. in its default options:

            $options = array_merge(array(
                        // Balance html tags
                        'balance' => 1,
                        // Decoding special html char like &lt; and &gt; which
                        // can be used to skip cleaning
                        'decode' => true
    Setting 'decode' to false seems to solve the issue without any negative side effects (so far ;-))
  • @dc_ao When i was looking into this editing content did not work with just changing decode to false, see this thread:
  • @Micke1101 I just fiddled around a bit width <code> sections and HTML characters in general and every interface (GUI and mail) behaves as expected now, including edits.

    BTW I run osTicked 1.10.1 
  • Can you post what you did to get it working?
  • @dc_ao I would do EXTENSIVE testing on your system if I were you...since you allowed '<' tags and HTML tags, you could've easily opened yourself to XSS.
  • @ntozier include/class.format.php line 295, changed 'decode' => true to 'decode' => false in the default config.

    @KevinTheJedi all I did was to disable the decoding of already encoded htmlspecialchars before sanitizing the content..
    Though I cannot imagine a certain vulnerability by this, I tried all kinds of scenarios to insert scripts and tags, and none of my attempts lead to an unexpected (resp. unsecure) result.
    If you could outline a scenario you have in mind, I will thankfully test it aswell.
Sign In or Register to comment.