> From: Claude Brisson [mailto:[EMAIL PROTECTED]] > > Jeff wrote : > > > By adding a $foo:noescape syntax, it would only be necessary to add the > > property to the node and some code to check it in ASTReference. > > Yes, but you have other ways to avoid char escaping than to introduce a > new syntax. For instance, you can set the content format of > the outer template to be "text/plain".
That isn't sufficient for what I consider the "typical use" of this feature: ## <?xml version="1.0"> <document> $some.reference is a normal String from a database, possibly obtained from user input. Must be escaped because it might have xml characters. $some.other.reference is known to be XML text, maybe from a prior template processing step, maybe from an XML data source. Guaranteed to be well-formed and safe. Both $some.reference and $some.other.reference must coexist in the same template. </document> ## This is not abstract or theoretical; I personally have to do this in my templates. Anyone using Turbine2's layout processing has to do it. Anyone who gets a lot of data from XML sources will likely have to do it too. > If you need a fine-grained control > of your own on whether or not escaping is occuring, I > guess you should write a tool to fullfit your needs. It is not possible to write a tool to "de-escape" the escaped data (since tool processing occurs first), so this would require leaving the default unescaped mode and then using an escape tool for *every single* reference. The vast majority of references, I think you would agree, do not contain well-formed XML, so this would mean $escapeTool($foo) for practically every single reference. This is not only cumbersome, but it represents a significant security hole as well - designers might miss spots, or (more likely) never would think about needing it in the first place. How many people writing webapps have a good understanding of cross-site-scripting vulnerabilities? Relatively few, I would guess. I'm willing to bet that most of the existing sites using velocity have such problems. Just to fully illustrate this point, the Forum Demo sample webapp that comes with Velocity is wide-open to CSS hacks. People using the Struts or JSTL jsp tags won't suffer from this problem because of a) sensible defaults and b) minimum effort required when the defaults aren't appropriate. > You need to track the state because you not only have to know whether to > escape chars or not, but which kind of escaping should > occur (for instance : single quoted vs double quoted strings). I'm a little confused by this. When escaping XML characters, what more is there than converting <, >, ', ", and & to <, >, ', ", and &? > My aim here is to free designers from the painful task of choosing the > right escaping at the right place, Please explain; looking at the JSTL code, their understanding of XML escaping matches mine - convert the 5 Characters Of Evil to entities. > and again this kind of > control can easily be done using a tool. I hope I have convinced you that a tool is not appropriate for this task. Some CSS links: http://httpd.apache.org/info/css-security/ http://www.cert.org/advisories/CA-2000-02.html Jeff Schnitzer [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
