durusmail: quixote-users: htmltext in PTL
htmltext in PTL
2004-12-10
2004-12-10
2004-12-10
2004-12-11
2004-12-11
htmltext in PTL
Mike Orr
2004-12-11
On Fri, Dec 10, 2004 at 04:49:38PM -0600, Jason Sibre wrote:
> Quoting Mike Orr :
> >
> > By the way, the one annoyance I've found with PTL is, would it please stop
> > encoding the other operands in a "+" expression?  Nine times out of ten
> > when I do:
> >      string1 + htmltextString
> > string1 is preformatted HTML and I want it left as is.   In my output
> > filter I had to do:
> >     output = top + htmltext(output) + bottom
> > or
> >     output = str(top) + str(output) + str(bottom)
> >
> > to make it behave.  ('top' and 'bottom' are htmltext from a PTL;
> > 'output' is whatever the page callable returned.)
> >
>
> Mike,
> I'm not positive I understand your complaint, but if I do, I think you must
have
> either found a bug in the version of Quixote you're using, or ...  maybe you
> don't 'get' the idea behind htmltext ...?
>
> The fact that htmltext automatically converts any string it's combined with
> (whether via "+" or string formating/substitution) is the whole purpose of
> htmltext's existence.  It provides a safety net that ensures (provided you
> don't deliberately undermine it) no data is sent to the browser without being
> properly escaped, whether that data came from literal strings in the source
> code, or was read from a database, etc.  This helps defend against cross-site
> scripting and other similar ills, with little or no developer effort.

I thought this safety net was the purpose of [html] functions, and htmltext
exists only to prevent that value from being re-escaped later.

> I think this means you have either already escaped the contents of 'output'
> (or you haven't escapedit, but you're assuming or you know it doesn't need to
> be escaped), but left it as a string (why didn't you just use htmlescape() to
> escape it, which returns an htmltext instance, or wrap it with htmltext() if
> you know it doesn't need to be escaped?),

For the same reason I don't put the header/footer calls themselves in
the page-specific callable.  If I did that, every single 'return' would
have to be an htmltext call or a header/footer call.  I want the
page-specific function worrying about its unique content, not about shared
issues that can be factored out.  So, I know 'output' is properly formatted
HTML.  As it is, I've put htmltext around it:
      # Inside Publisher.filter_output() .
      output = header_ptl() + htmltext(output) + footer_ptl()
because I have to, but I wish I didn't.

--
-Mike Orr (aka. Sluggo), mso@oz.net  (iron@sense-sea-MegaSub-1-465.oz.net)
   http://sluggo.kicks-ass.org/                  Cxu vi parolas Esperante?

reply