On 3/6/08, George Adams <g_adams27@hotmail.com> wrote:
Joe, it's not just malicious activity I'm worried about (though that is a fundamental security concern). Unencoded HTML can break a page with frightening ease. Take this simple field:
<input type="text" name="booktitle" value="$title">
Now if $title has the value: How to Say "I Love You" in 50 Languages, your HTML code will be rendered like this:
<input type="text" name="booktitle" value="How to Say "I Love You" in 10 Languages>
and is now hopelessly broken. The CGI param $booktitle will contain "How to Say ", and the rest of the book title (in addition to breaking the HTMLtag) will be lost.
Yep if you find any instances of this happening bug report it (this of course isn't what I would call unencoded HTML). I can hardly expect all the library staff to remember not to use
double-quotes in any Koha text form (or any other unsafe characters like < ,
or & ). Indeed, should they really be forced to give up such common characters just to workaround the problem?
No, and in fact they don't http://203.97.214.51:8080/cgi-bin/koha/opac-detail.pl?biblionumber=2 I think I'll try mocking up something with HTML::Entities, at least in the
most critical parts of the "Add Marc Item" form. Meanwhile, if no one objects, I'll put in a bug report for it too.
If you put in bug report for specific areas where enescaped html is causing a problem, then we can simply edit the templates to add a ESCAPE="HTML" to the TMPL_VAR that needs it. Please don't convert things to entities to store in the database. This data is used by more than just web browsers. So by all means bug report away, but if you give url's of pages where unescaped characters are causing problems then it will be much more useful Thanks Chris