On Dec 9, 2010, at 3:34, Ferenc Kovacs <i...@tyrael.hu> wrote: > On Thu, Dec 9, 2010 at 12:15 PM, Pierre Joye <pierre....@gmail.com> wrote: > >> hi, >> >> As far as I remember we discussed that already back to the php<I don't >> mention it> discussions. It was not accepted because of the little >> gains in regard to the major BC breaks. >> >> However I would prefer, as far as it is technically possible, >> deprecate their usage (notices/warnings) and promote filter usage >> instead. The filter API can also be improved to match what we can find >> in other platform (perl's cgi module for example is quite good) and >> make the input data processing even more user-friendly. >> >> Cheers, >> >> > yeah, to throw in something: > I like the Safe levels and the tainted support in ruby: > http://www.ruby-doc.org/docs/ProgrammingRuby/html/taint.html > > <http://www.ruby-doc.org/docs/ProgrammingRuby/html/taint.html>and I like the > idea that Inspekt provides: > http://funkatron.github.com/inspekt/ > <http://funkatron.github.com/inspekt/> > "Inspekt acts as a firewall API between user input and the rest of the > application. It takes PHP superglobal arrays, encapsulates their data in an > "cage" object, and destroys the original superglobal. Data can then be > retrieved from the input data object using a variety of accessor methods > that apply filtering, or the data can be checked against validation methods. > Raw data can only be accessed via a 'getRaw()' method, forcing the developer > to show clear intent." > > I like the explicitness of the filtering, but I think that we should allow > the developers to decide whether to use it or not.
You just described exactly how the filter extension works when you enable a default filter. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
