[Koha] HTML not being encoded for display?
chris at bigballofwax.co.nz
Thu Mar 6 19:15:42 NZDT 2008
On 3/6/08, George Adams <g_adams27 at 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
> 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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Koha