-
Incident report
-
Resolution: Fixed
-
Major
-
1.6
-
None
I ran into this same issue, also from unix output (ps). The basic flow of data getting onto a screen is:
screen.php -> screen.inc.php
on line 373 of screen.inc.php a string value like this is formatted with:
Code:
$value = nl2br(nbsp(htmlspecialchars($row["value"])));
which is fine b/c the nl2br is added outside of the htmlspecialchars function, so the <br /> that nl2br inserts for a newline is not encoded by htmlspecialchars.
The flow is then:
line 384 of screen.inc.php -> AddRow function of the CTable class in ctable.inc.php -> PrepareRow function of the CTable class in ctable.inc.php -> AddItem function of the CRow class in ctable.inc.php -> AddItem function of CTag class in ctag.inc.php
on line 107 of ctag.inc.php you have
Code:
array_push($this->items,str_replace(array('<','>','"'),array('<','>','"'),$value));
and it is this which then effectively html encodes the <br /> tags added above and causes the text to render the multiple lines as one long line.
I don't know in what situations this is actually useful (so text would get here w/o passing through the first encoding step), so I don't want to just remove it (though that works for this particular case). What I changed it to was:
Code:
array_push($this->items,str_replace('<br />', '<br />', str_replace(array('<','>','"'),array('<','>','"'),$value)));
which just adds an additional replace searching for encoded <br /> tags and reverts them to unencoded ones. This would still break in a situation where:
1) your text has <br /> tags in it
2) it does not pass through the first encoding step that this path does
In that case line 107 would encode them but my change would unencode them. For us this shouldn't be an issue as no data we capture is html, but someone that really knows what they are doing could probably fix this better.
Thanks.
http://www.zabbix.com/forum/showthread.php?p=38790#post38790