[Koha] HTML not being encoded for display?

George Adams g_adams27 at hotmail.com
Fri Mar 7 10:31:59 NZDT 2008

Yes, I am - 3.0alpha .  And I may have been too optimistic with the changes I made.  For example, here's my experiment with opac-results.tmpl  .  

1) I had a record entered with the somewhat silly title (245a) of "One Two <Three> Four", with a general note (500a) of "Here is a note".  When I did a search for "note" in the OPAC, this record came up in the search results with the title displayed as "One Two Four" (i.e. <Three> was unescaped and treated as a tag, and not displayed as literal text).

2) Next, I went into opac-results.tmpl , found the appropriate <!-- TMPL_VAR NAME="title" --> line and changed it to <!-- TMPL_VAR NAME="title" ESCAPE="HTML" --> .  When I reloaded the search results page, the title was correctly displayed as "One Two <Three> Four" as I had hoped.  So far, so good.

3) But next, I did a search for "Two" - i.e. a word that appears in the title of the book.  This time, the search results displayed the following:  One <span class="term">Two</span> <Three> Four

With that, I discovered that HTML appears to sometimes be injected into tags like "title" (in order to highlight the word or whatever), and that simply escaping that variable wasn't going to work.  

Ideally, the variable would be retrieved from the DB, HTML-escaped, then wrapped in whatever other HTML tags need to be included, and rendered.

Practically... I have no idea how to do that.  I guess we're just going to have to do our best to work around it.

Date: Fri, 7 Mar 2008 08:20:57 +1300
From: chris at bigballofwax.co.nz
To: g_adams27 at hotmail.com
Subject: Re: [Koha] HTML not being encoded for display?
CC: koha at lists.katipo.co.nz

Are you working with Koha 3 George?


On 3/7/08, George Adams <g_adams27 at hotmail.com> wrote:

Thanks for the tip about adding ESCAPE="HTML" to the template tags - that's a nice feature.  I've been able to change additem.tmpl, opac-results.tmpl, opac-detail.tmpl and opac-MARCdetail.tmpl to make our entries display correctly.  (That only scratches the surface, of course; I'm guessing that the Right Thing would be to change pretty much every single template that displays any user-generated content so that it's escaped.  But I'm also guessing that's a big undertaking.)

Date: Thu, 6 Mar 2008 19:15:42 +1300
From: chris at bigballofwax.co.nz
To: g_adams27 at hotmail.com

Subject: Re: [Koha] HTML not being encoded for display?
CC: koha at lists.katipo.co.nz

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 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 HTML tag) 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



Shed those extra pounds with MSN and The Biggest Loser! Learn more.

Connect and share in new ways with Windows Live.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.katipo.co.nz/pipermail/koha/attachments/20080306/2f24a7e6/attachment-0001.htm 

More information about the Koha mailing list