<br><br><div><span class="gmail_quote">On 3/6/08, <b class="gmail_sendername">George Adams</b> <<a href="mailto:g_adams27@hotmail.com">g_adams27@hotmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; 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="st" name="st" class="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="st" name="st" class="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="st" name="st" class="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="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; 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">http://203.97.214.51:8080/cgi-bin/koha/opac-detail.pl?biblionumber=2</a><br> </div><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>I think I'll try mocking up something with <span id="st" name="st" class="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>