Re: A better XSS trap (Feedback wanted)

Hej Egbert,

thank you for your feedback (and that you like it ;)).

I see only one downside, and that is that IMHO the position where
things are done is slightly architecturally incorrect: you typically
want to do htmlentities() as the last operation, or second last
sometimes (before an nl2br/bbcode formatter or so).

My idea was: One normally applies few sets of functions to most of the
variables most of the time. Maybe one set for normal fields, one for
textareas, and one for urls. Having them in custom filter methods makes
view code shorter and more maintainable. And you are right, for special
cases there is always ->raw(). I don't really see the downside ;).

Another worry: did you test the speed of your approach? I haven't
looked into the source, but it appears quite some magic requires
__get, __set and __call, which may slow down the view element of the
page a bit.

I have this worry as well as there is some magic going on indeed. I did
not test performance yet. It should absolutely be verified with
benchmarks, but my guess is the following:
For most views it should not be a performance problem, when there are
only up to a few dozen variables access in the view. My implementation
does lazy decoration (as in lazy evaluation), meaning that the strings
are almost only decorated on demand and that _not_ everything is
recursed in the beginning. This means one ends up with a number of
instantiated objects roughly matching the number of variables actually
accessed in the view.
However, for heavily dynamic-data-dependent views, such as large tables,
performance could be a problem. But then it would still be possible to
access the whole table using ->raw() and thereby circumvent decoration
of every single cell. But of course this puts back the duty to call
htmlentities manually.

(btw, as another (on topic) shameless plug, my home cooked compiling
template engine does htmlentities or htmlspecial chars by default when
echoing expressions

Actually I thought about having a default escape method using __toString
in my StringFilter as well, but then I disabled it by default. It is
still possible to enable it again and register one filter as the
__toString default filter, but I do not recommend it. In my eyes it is
better to always be forced to choose the right filter depending on the
context and for example html, urls or javascript are different contexts
that require different filters.

and allows pure PHP code,

I had a quick look on the website and do not see a large difference to
Smarty, expect that mplate seems to put a Smarty-like syntax closer to
PHP-Code. Still there is a new syntax to learn. Why not use pure PHP
instead? <?=$some_var?> or {$some_var} is no big difference in my eyes,
only that the first is well known and does not need to be compiled an
extra time. What did I miss ;)?

if you're cool with that, I may want to add your filter class thingy
as an extention to it, though, for more fine grained control)

Sure! I am happy you like it. It's published unter GPL. It would be
great if you link in case you use my
code. Note that this was a prototype. I already have some future changes
in mind to further decrease the already small learning curve and at the
same time add some more flexibility. Get the latest code from the SVN.