[Koha] HTML not being encoded for display?

[George Adams]

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 
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




_________________________________________________________________
Shed those extra pounds with MSN and The Biggest Loser!
http://biggestloser.msn.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.katipo.co.nz/pipermail/koha/attachments/20080306/09a204ef/attachment.htm