> > 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?> > > I'm afraid that this is getting us back to magic_quotes_gpc:
Negative - magic_* is global type behavior that's automatic - evil... > because now I might want to write > > $first_name=$Object->FirstName; > > and then do something with $first_name that isn't writing it into > HTML. magic_quotes_gpc was effective protection against a certain But you'd always be writing into HTML. The escaping as it's done above is only after a regular data object has been adapted/pushed into an HTML template. The original data is never changed, and the escaping is use case specific. Back in my model/controller, my data object gives raw data, just as it's stored. I could write an adapter and push data in, that let's say, is for SQL - JSON - CSV - XML - etc. Each adapter would wrap the data as appropriate. If I had an adapter for MySQL SQL generation and one for Oracle SQL generation, they would even escape things differently, based on the type of SQL (and connection resource/charset/etc in fact). Very different from magic_* > category of HTML injection faults, but it made it difficult to write > entirely correct code that processes the content of strings. I prefer > the model of "escape at the time of output" rather than preemptive > escaping: particularly these days, where you might be escaping a > variable to be a Javascript string literal instead of an HTML code. > > Today people are realizing that HTML/Javascript injection attacks > are difficult to stop (there are lots of clever ways to inject > Javascript that you'd never think of), and some systems are taking > different approaches. ASP.NET, for instance, has an "application > firewall" built in that looks for dangerous inputs in form variables and > that will abort your application if you get fed junk. Although my first > impression is that this is "magic_quotes_gpc all over again", and I've > definitely seen the system block legitimate input, Microsoft has done a > good job of justifying this behavior. No argument with HTML injection being a mess, but the above example is exactly "escape at the time of output" - and escape based on the exact destination, so it's very granular. > > 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. > > It makes some people feel dirty, but you can do this with global > variables, assuming your template system remembers to set them when you > get in or out of a template. My own "php on nails" system has quite a Mine does - they aren't "global" but scoped only for that template. When an object is pushed in, it's adapted/wrapped with an object that is designed specifically for output in whatever type of template I'm dealing with. > few functions that behave differently if serving a web page or run from > the command line. Ditto - PHP on nails, I like that... H _______________________________________________ New York PHP User Group Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk http://www.nyphp.org/show_participation.php
