<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
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.)<br><br><br><blockquote><hr>Date: Thu, 6 Mar 2008 19:15:42 +1300<br>From: chris@bigballofwax.co.nz<br>To: g_adams27@hotmail.com<br>Subject: Re: [Koha] HTML not being encoded for display?<br>CC: koha@lists.katipo.co.nz<br><br><br><br><div><span class="EC_gmail_quote">On 3/6/08, <b class="EC_gmail_sendername">George Adams</b> <<a href="mailto:g_adams27@hotmail.com">g_adams27@hotmail.com</a>> wrote:</span><blockquote class="EC_gmail_quote" style="padding-left: 1ex;">
<div>
Joe, it's not just malicious activity I'm worried about (though that is a fundamental security concern). Unencoded <span id="EC_st" class="EC_st">HTML</span> can break a page with frightening ease. Take this simple field:<br>
<br><input type="text" name="booktitle" value="$title"><br><br>Now if $title has the value: How to Say "I Love You" in 50 Languages, your <span id="EC_st" class="EC_st">HTML</span> code will be rendered like this:<br>
<br><input type="text" name="booktitle" value="How to Say "I Love You" in 10 Languages><br><br>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 <span id="EC_st" class="EC_st">HTML</span> tag) will be lost.</div>
</blockquote><div><br><br>Yep if you find any instances of this happening bug report it (this of course isn't what I would call unencoded HTML).<br></div><br><blockquote class="EC_gmail_quote" style="padding-left: 1ex;">
<div>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?</div>
</blockquote><div><br>No, and in fact they don't <br><a href="http://203.97.214.51:8080/cgi-bin/koha/opac-detail.pl?biblionumber=2" target="_blank">http://203.97.214.51:8080/cgi-bin/koha/opac-detail.pl?biblionumber=2</a><br> </div><br>
<blockquote class="EC_gmail_quote" style="padding-left: 1ex;"><div>I think I'll try mocking up something with <span id="EC_st" class="EC_st">HTML</span>::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.</div>
</blockquote><div><br>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.<br>Please don't convert things to entities to store in the database. This data is used by more than just web browsers.<br>
<br>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<br><br>Thanks<br><br>Chris<br></div><br></div><br>
</blockquote><br /><hr />Shed those extra pounds with MSN and The Biggest Loser! <a href='http://biggestloser.msn.com/' target='_new'>Learn more.</a></body>
</html>