Re: Re: Packages accessing super globals

Joe Stump wrote:

The one advantage of such a setup that I can see is that PEAR could do some sanitization of the $_GET/$_POST variables before you start working on them. That being said it's a "nice thing to have" not a "OMG! You're using $_GET directly?!?!?111" thing, IMO. I would think a separate package (HTTP_Request_Sanitize?) would make more sense than shoving it where it don't belong (in PEAR's base classes). That way authors can use $_GET/$_POST directly (why a low level PEAR package would ever need that is beyond me - I guess Auth would though) or they can use the package.

I agree that if it's wanted, it should be placed in a separate package, and its use should be OPTIONAL. This whole discussion started (in the aforementioned IRC channel) when I noticed a problem in PEAR_Info (already fixed in CVS), related to $_SERVER['PHP_SELF'] (http://www.phpdoc.info/commits/8116 -- see my recent blog entry if this commit makes no sense to you). Let's be realistic, examples, tests and documentation aside, there really aren't that many places where PEAR does (or should!) use the superglobals. I'm pretty sure this was discussed on this list, a few months back. There are equally few (estimating, here) places where PEAR code actually does any sort of output. That said: we suck at filtering, and escaping. We need to show more "best practice" examples. Last comment: if we decide to implement something like this common method of accessing input, filtering it is acceptable, but it should by NO MEANS be escaped. Escaping must take place at output-time. http://brainbulb.com/talks/php-security-briefing.pdf S