From: Honza M. <hon...@ec...> - 2003-03-04 21:52:25
|
On =DAt, 2003-03-04 at 12:11, Mitra wrote: > Any more thoughts on this? >=20 > I've fixed it on my copy by setting register_globals on, but many > people installing APC-AA won't have access to php.ini Sure, we have to fix it. > At 9:54 AM +1100 26/2/03, Mitra wrote: > > Maybe it is not so much work .... > > We have code that is all over the place > > if (!get_magic_quotes_gpc()) { > > // Overrides GPC variables > > if( isset($HTTP_GET_VARS) AND is_array($HTTP_GET_VARS)) > > for (reset($HTTP_GET_VARS); list($k, $v) =3D each($HTTP_GET_VARS)= ; > > ) > > $$k =3D Myaddslashes($v); > > if( isset($HTTP_POST_VARS) AND is_array($HTTP_POST_VARS)) > > for (reset($HTTP_POST_VARS); list($k, $v) =3D > > each($HTTP_POST_VARS); ) > > $$k =3D Myaddslashes($v); > > if( isset($HTTP_COOKIE_VARS) AND is_array($HTTP_COOKIE_VARS)) > > for (reset($HTTP_COOKIE_VARS); list($k, $v) =3D > > each($HTTP_COOKIE_VARS); ) > > $$k =3D Myaddslashes($v); > > } > > We could change MyAddSlashes to set the GLOBALS, variables if > > register_globals was off? Yes, it is quick and dirty solution. We can copy all variables from $_GET, $_POST, $_SERVER, $_COOKIE, ... variables to the $GLOBALS in MyAddSlashes() or similar function. It will work. On the other hand the $_GET, ... superglobal variables was introduced because of bigger security of the code. If we register ALL variables from superglobals arrays, we loose this advantage of security. So, I agree we can do it as quick solution, but if we want to benefit from security advantages of superglobal variables, we have to rewrite the current code to use it. My suggestion is to use superglobal variables at least in newly written code, for now. Note: We can use import_request_variables() function to do it - See: http://www.php.net/manual/function.import-request-variables.php > > Anyway - shouldn't this be an include, since we do it the same way > > almost everywhere? Yes, good idea. > > I can see that include/config.php3 is called after this but I > > can't see anything in config.php3 that depends on these variable, so > > we could just call a script, say > > $GLOBALS[AA_INC_PATH]/setvariables.php3 AFTER config.php. > > I think the code would also need to handle a few extra variables > > like $DOCUMENT_ROOT becoming $_SERVER['DOCUMENT_ROOT'] It's the same problem as with $_GET, ... only the replace to right form is easier - we know all possible variable names. Note: be carefull with the search and replace - the superglobal arrays are supported from PHP v4.1.0, but AA should support PHP v4.0.6 > > This could be easily done with a Tags-find-replace since we aren't > > changing functionality, only variable names. The hard part is that > > we need to work in the pre 4.2.0 case as well, so it might be best > > to do it all in include/setvariables.php3 e.g. > > if somecall(register_globals) { /// Not sure how to test this > > $DOCUMENT_ROOT =3D $_SERVER['DOCUMENT_ROOT'] > > } if( ini_get('register_globals') ) ...=20 Honza > > Thoughts .... > > - Mitra > > At 1:29 PM +0100 25/2/03, Honza Malik wrote:=20 > > > Hi Mitra, > > >=20 > > > I think you upgraded PHP to version >=3D4.2.0, where PHP > > > configuration > > > directive register_globals is set to OFF by default. Current AA > > > runs > > > only with the register_globals set to ON. We should change the > > > code of > > > AA to use superglobals variables $_GET, $_POST, $_COOKIE, ..., but > > > is > > > uis quite a lot of work. On the other hand, the new settings of > > > PHP > > > (register_globals=3DOFF) is safer, so we should do it. > > >=20 > > > See > > > http://www.php.net/manual/en/language.variables.predefined.php#lang= uage.variables.superglobals > > >=20 > > > Honza > > >=20 > > > On P=E1, 2003-02-21 at 14:02, Mitra wrote: > > > > Hi > > > > > > > > Something seems to have changed on my home system, so that > > > global > > > > variables aren't getting set. I don't think its an APC change > > > > because a backup version stopped working as well. I have > > > upgraded > > > > the OS (Mac OSX) recently so its possible that a config file > > > > changed, so I'm really looking for help to find out what > > > changed. > > > > > > > > There is NO php.ini in use. > > > > > > > > I've look on include/init_page and get_magic_quotes_gpc() is > > > returning 1 > > > > so the piece of code that sets the variables isn't being run. > > > > > > > > If that code is NOT run, then how are the variables set from the > > > URL > > > > i.e. from HTTP_GET_VARS? > > > > > > > > - Mitra > > > > > > > > -- > > > > Mitra Technology Consulting - www.mitra.biz - mi...@mi... > > > > 02-6684-8096 or 0414-648-0722 > > > > > > > > Life is a Mystery to be Lived, not a Problem to be Solved > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This SF.net email is sponsored by: SlickEdit Inc. Develop an > > > edge. > > > > The most comprehensive and flexible code editor you can use. > > > > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day > > > Trial. > > > > www.slickedit.com/sourceforge > > > > _______________________________________________ > > > > Apc-aa-coders mailing list > > > > Apc...@li... > > > > https://lists.sourceforge.net/lists/listinfo/apc-aa-coders > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by:ThinkGeek > > > Welcome to geek heaven. > > > http://thinkgeek.com/sf > > > _______________________________________________ > > > Apc-aa-coders mailing list > > > Apc...@li... > > > https://lists.sourceforge.net/lists/listinfo/apc-aa-coders > > -- > > Mitra Technology Consulting - www.mitra.biz - mi...@mi... > > 02-6684-8096 or 0414-648-0722=20 > >=20 > > Life is a Mystery to be Lived, not a Problem to be Solved >=20 >=20 >=20 > --=20 > Mitra Technology Consulting - www.mitra.biz - mi...@mi... > 02-6684-8096 or 0414-648-0722=20 >=20 > Life is a Mystery to be Lived, not a Problem to be Solved >=20 |