#1019 closed defect (fixed)
Component names in tickets not escaped properly
Reported by: | Owned by: | Jonas Borgström | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | ticket system | Version: | 0.8 |
Severity: | minor | Keywords: | ticket component bug |
Cc: | sns@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
The symptom is that when editing a ticket in Trac 0.8, an incorrect component is selected. This happens when a component has a character (e.g. >) in its name that needs to be escaped in HTML.
A possible fix might be to wrap the option.name
and $selected
variables on line 4 of source:/trunk/templates/macros.cs in the ClearSilver html_escape function, so that boths sides of the equality test are escaped in the same way. Unfortunately, my testing indicates that html_escape()
isn't available, despite what the ClearSilver docs suggest ("Unknown function html_escape called").
Alternatively, we could escape the values in source:/trunk/trac/Ticket.py (line 324) before they get put into the HDF. This might be more appropriate, but would involve digging further into util.sql_to_hdf
and so on.
Attachments (0)
Change History (5)
comment:1 by , 20 years ago
comment:2 by , 20 years ago
My apologies; the previous comment timestamped Fri Dec 3 14:37:46 2004
was from me.
comment:3 by , 20 years ago
For what it's worth, there is a similar problem with the Roadmap display. The "active tickets" and "closed tickets" links use special characters that are not escaped properly. Modifying source:/trunk/trac/util.py so that the last line of add_to_hdf
sets the value to escape(str(obj))
instead fixes the HTML error. This does not appear to have any negative side effects.
comment:4 by , 19 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
This has been fixed some time ago IIRC.
It turns out that modifying
util.sql_to_hdf
to solve this problem is fairly trivial. On line 173 in source:/trunk/trac/util.py you can wrap the last parameter,row[0]
so that it readsescape(row[0])
instead. This seems like a fairly generic change that shouldn't affect anything negatively, and it definitely solves the problem I was having.