Hi, It seems you had an interesting idea, but AFAIK it'll not incorporated in core by PHP Team. Yeah, sounds bad, but you cannot simply turn all variables into objects and try to get them.
Seems you're trying something like that: $_GET['foo']->asString(); // echo: Bar This will never happen, PHP will not change its behavior to fullfil it. I already thought like you and I even spent some time to develop a tool to simplify my job. The concept you try to implement is named Poka-Yoke (http://en.wikipedia.org/wiki/Poka_yoke) - and please again... do not tell me this is like Pokémon. I already asked here when I was developing this feature about a limitation PHP currently has, but this is not the current discussion. Just to let you know, if you are thinking to do something as I already showed you as example, forget it. If you are trying something different, like: taint_string( $_GET['foo'] ); // echo: Bar Then you need to think correctly what do you want to achieve. There are zillions of PHP applications running out there and none of them will be converted to use taint-package. The first example illustrate how the PHP should behavior with a taint extension; and access the data directly: $_GET['foo'] should throw an error. My idea: Keep things simple and validate all your data using PHP. You do not have to go "behind the scenes" and create a C library to achieve it. If you are interested, I already implemented the PokaYoke approach and I put it available for you at: http://blog.bisna.com/files/PokaYoke.zip I also published the running package: http://blog.bisna.com/files/PokaYoke/ Take a look at the examples... I published the phps files if you are lazy and do not want to download the zip file. You can incorporate the module and keep it project specific. My implementation was never being released to public, but it works as expected. It's better to make a project specific feature and use it instead of try to create a module. Best regards, On 8/9/07, Wietse Venema <[EMAIL PROTECTED]> wrote: > Late last year I started a discussion on this list with a proposal > to add Perl/Ruby-like taint support to PHP - a feature that a > developer may turn on to find out where to insert explicit cleaning > operations to avoid code injection etc. vulnerabilities. With > applications that are explicitly written to be taint ware, taint > support may also help at run-time as an additional safety net. > > In the unavoidable trade-off between performance and developer > impact, this approach minimizes the performance hit; the developer > provides the explicit cleaning operations. Other taint-for-PHP > approaches make a different trade-off; they typically avoid developer > impact altogether, but come at the cost of a larger performance hit. > > After a bunch of other work that needed to be done I've resumed > work on PHP and I'm currently working on a rough prototype that > supports taint in the core and in a bunch of standard built-ins. > Overhead is minimal because it's just setting and testing a few > normally unused bits in the zval structure. I expect to get some > actual performance data once the implementation is complete enough, > and to have a first implementation out the door sometime in September. > > Wietse > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9166-6902 MSN: [EMAIL PROTECTED] URL: http://blog.bisna.com São Carlos - SP/Brazil
