NYCPHP Meetup

[Eddie Drapkin]

On Sat, Aug 29, 2009 at 6:21 PM, Hans Zaunere<lists at zaunere.com> wrote:
> Yeah something like this could be handy, certainly.  I typically push/adapt
> an object into the template which is property overloaded.  Then something
> like:
>
> <?=$Object->FirstName?>
>
> Outputs correctly escaped (or processed in any other way depending on what
> the overload wants to do) content.  Quite handy and has proved effective.
>
> It does seem that it'd be handy to have some type of "stdout" processing
> hook that can be overridden, while providing a shorthand for working in
> templates.
>

I played around with a class for a while that was something like this:

abstract class AbstractViewDataBucket {
	/*
	 * This will be called for manually set private members.
	 */
	public function __get($var) {
		return htmlspecialchars($this->$var);
	}
	
	/*
	 * This is here because manually overridden variables
	 * that aren't already set are set publicly, although
	 * __set() is called when they're defined.  This allows us
	 * to make classes with no pre-defined members.
	 */
	public function __set($var, $val) {
		$this->$var = htmlspecialchars($val);
	}
}

And all my classes that held data for templates worked "magically."
So, something like:
$foo = new RandomViewDataThatExtendsTheAformentionedClass();
$foo->bar = 'baz';
$foo->hi = '<a href="google.com">hello</a>';

... (in another file):
<html>
<?php echo $foo->bar; ?>
<table>
<?php echo $foo->hi; ?>
...

This sort of crap would work as expected.  Similarly (and sort of
derailing), before I switched to prepared statements and actually
manually escaped database strings (thank god that period of my life is
over), I had used another class that worked similarily, only calling
mysqli_real_escape_string() instead of htmlspecialchars().  I'm a huge
fan of small, single-use classes, so this schema worked well for me.
It also allows overriding if necessary, like one class that needed to
verify that data was UTF8, while other classes didn't care so much.
Another idea with the overriding of "stdout" processing, you could
abuse output buffering and the callback support that comes with it,
although a major initial hurdle would be deciding what to escape.  Any
solution I can think ofresults in spending more time supporting the
output handling than would be saved by using them.  Doesn't mean it's
impossible, of course ;)

And on another note, historically speaking, things that offer a sense
of security that are built into PHP (magic quotes and safe mode,
anyone?) aren't very useful and are often seen as a false sense of
security.  Having something like <?htmlspecialchars= ?> (and I'm 99%
sure <?hsc= would be a pretty easy patch) built into the language
would probably wind up with a lot of sites with double escaped
characters, which is awful, or there'd be some way to circumvent its
protection that would instantly make a lot of sites insecure to XSS
attacks, so I'm definitely not in favor of this sort of feature.  Once
again, my opinion only.