Bug #17758 Updated: magic_quotes_gpc causes more trouble than it helps

ID: 17758 Updated by: msopacua@idg.nl Reported By: php.net@odi.ch Status: Closed Bug Type: PHP options/info functions PHP Version: 4.0CVS-2002-06-14 New Comment: I really don't get the 'poor-quality' statement. The feature protects the weak and unwary against sql injection and it's easy to work around it, using get_magic_quotes_gpc(). All you're asking for, is not having to verify client-sent data, which IMO is poor quality to begin with and link that to code-reuse and deployment problems. The problem is with your assumptions - not the feature. Example: <?php // This function should be called whenever some variable is directly inserted // into the database, when coming from $_REQUEST (and of course it's partials // $_GET, $_POST etc.). function safe_addslashes($string) { // Using a static variable, speeds up multiple calls. static $setting=-1; if($setting === -1) { $setting = get_magic_quotes_gpc(); } return ($setting) ? $string : addslashes($string); } // This function should be called whenever some variable is directly output // to the browser or a datasource that is not affected by quotes, when coming // from $_REQUEST (and of course it's partials $_GET, $_POST etc.). function safe_stripslashes($string) { static $setting = -1; if($setting === -1) { $setting = get_magic_quotes_gpc(); } return ($setting) ? stripslashes($string) : $string; } ?> Previous Comments: ------------------------------------------------------------------------ [2002-06-14 06:33:46] hholzgra@php.net #1 most of them do not even *know* that their code relies on it, as they haven't experienced problems with quotes and stuff in queries as the magic takes care of it #2 changing magic_quotes_gpc at runtine ... requires the engine to remember which variables were filled with values from GET/POST/COOKIE this is not to difficult with the track vars or the new superglobals as there you can rely on the namespace, but it would be a nightmare in combination with register_globals=on ------------------------------------------------------------------------ [2002-06-14 06:09:14] php.net@odi.ch I forgot to mention a *quick* solution to this problem: Just make ini_set work at runtime. I know its hard because the magic happens now before execution starts. This could maybe be changed a little bit. ------------------------------------------------------------------------ [2002-06-14 06:06:42] php.net@odi.ch Agree with you that PHP can not detect if code relies on this feature. So the actual problem is: How do I tell the developer that the behaviour changed (or will change). Obviously just mentioning the fact in the release notes is not enough, because this is very subtle but quite important to know. -=| This is a problem that needs proper change management |=- So first developers and system managers must be accustomed (this is the hard part) not to use this feature. Workarounds must be provided (functions that reverse the effect). Documentation must be updated. Books must be changed (this is the timey task). Finally the specs can be changed and the feature can be removed safely. This process may take years. It's not possible to change it within two releases or so. Still, all this doesn't mean that you should simply forget about it. As I said this issue need proper change management. It takes the time it needs. But it only starts when you support it. ------------------------------------------------------------------------ [2002-06-14 05:43:52] hholzgra@php.net the java way of deprecating things does not work here because of the magic used, there is no way (i can think of) how PHP can detect that code relies on this feature at any point, this is *very* different to just deprecating a method, member variable, interface, class or package so turning it of by default in php.ini-recommended is all we can do about it for now, turning it off by default would be a bad idea as the effect would be far less obvious as the problems that arise with register_globals=off, and that move already caused us a lot of trouble, and totaly removing the 'feature' would be even worse ------------------------------------------------------------------------ [2002-06-14 03:57:54] php.net@odi.ch I was never talking about "now". I said "in the future". I do not want to urge anybody. Nobody is forced to use a new PHP release with existing code. Nor can anybody expect to use a new PHP release without touching existing code. Once more may I ask you to reopen this request. Otherwise you will forget it. We want PHP to be of high quality. This includes we have to get rid of poor-quality concepts. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/17758 -- Edit this bug report at http://bugs.php.net/?id=17758&edit=1