Hi all
I thing we all agree on removal of this security evil script. Me and Marc already had non public discussion on this topic, however I thing it should go on this list, so lets start it again :-).
Basically there is need for some function to grab required parameters from request and clean up GLOBALS array in case of register_globals is on.
I suggested to create some function like:
PMA_grabParameter($name, $request, $sanitizing = 'none', $required = TRUE)
The request parameter might not be needed, but it's up to discussion.
While Marc came with way how Moodle does it:
Moodle does this (I did not pasted the full clean_param() function)
$id = optional_param('id', 0, PARAM_INT); $name = optional_param('name'); $edit = optional_param('edit'); $idnumber = optional_param('idnumber');
function optional_param($varname, $default=NULL, $options=PARAM_CLEAN) {
if (isset($_POST[$varname])) { // POST has precedence $param = $_POST[$varname]; } else if (isset($_GET[$varname])) { $param = $_GET[$varname]; } else { return $default; }
return clean_param($param, $options); }
Comments?
I do not thing it is good idea to have optional parameters in most of code.
Michal Čihař schrieb:
Hi all
I thing we all agree on removal of this security evil script. Me and Marc already had non public discussion on this topic, however I thing it should go on this list, so lets start it again :-).
Basically there is need for some function to grab required parameters from request and clean up GLOBALS array in case of register_globals is on.
cleanup is already done in grab_globals
I suggested to create some function like:
PMA_grabParameter($name, $request, $sanitizing = 'none', $required = TRUE)
The request parameter might not be needed, but it's up to discussion.
While Marc came with way how Moodle does it:
Moodle does this (I did not pasted the full clean_param() function)
$id = optional_param('id', 0, PARAM_INT); $name = optional_param('name'); $edit = optional_param('edit'); $idnumber = optional_param('idnumber');
function optional_param($varname, $default=NULL, $options=PARAM_CLEAN) {
if (isset($_POST[$varname])) { // POST has precedence $param = $_POST[$varname]; } else if (isset($_GET[$varname])) { $param = $_GET[$varname]; } else { return $default; } return clean_param($param, $options);}
Comments?
// ifsetor() ;-) function checkRequest($name, $default = null) { if ( isset( $_REQUEST[$name] ) ) { return $_REQUEST[$name]; }
return $default; }
i think in most cases PMA should use $_REQUEST directly and use one of the above function only to set default values
using of $_REQUEST makes it more clear where this variable came from, reminding the developer always to take care with this variables!
and i think its not good to always 'clean' variables
what will you clean of? you can not decide what users inserts into her database or they name her tables and fields
you just have to take care to escape the input correctly before inserting or displaying - but not cleaning!
and if the variable is a choice of options you have to check against the original choices (in_array or array_key_exists)
Hi
On Wed, 07 Dec 2005 10:38:19 +0100 Sebastian Mendel lists@sebastianmendel.de wrote:
Michal Čihař schrieb:
Basically there is need for some function to grab required parameters from request and clean up GLOBALS array in case of register_globals is on.
cleanup is already done in grab_globals
Yes I know, but we want to drop it ;-).
// ifsetor() ;-) function checkRequest($name, $default = null) { if ( isset( $_REQUEST[$name] ) ) { return $_REQUEST[$name]; }
return $default;}
i think in most cases PMA should use $_REQUEST directly and use one of the above function only to set default values
using of $_REQUEST makes it more clear where this variable came from, reminding the developer always to take care with this variables!
I also suggested that, however I got convinced that grabbing variables is better way. Now I can not find reason for that :-).
and i think its not good to always 'clean' variables
what will you clean of? you can not decide what users inserts into her database or they name her tables and fields
you just have to take care to escape the input correctly before inserting or displaying - but not cleaning!
Clean was also meant for type checking - if you want int, you will get int and no some evil text.
and if the variable is a choice of options you have to check against the original choices (in_array or array_key_exists)
You're right.
Sebastian Mendel a écrit :
Michal Čihař schrieb:
Hi all
I thing we all agree on removal of this security evil script. Me and Marc already had non public discussion on this topic, however I thing it should go on this list, so lets start it again :-).
Basically there is need for some function to grab required parameters from request and clean up GLOBALS array in case of register_globals is on.
cleanup is already done in grab_globals
I am in favor of dropping grab_globals, because it's too difficult to secure and to prove that it's been secured.
I suggested to create some function like:
PMA_grabParameter($name, $request, $sanitizing = 'none', $required = TRUE)
The request parameter might not be needed, but it's up to discussion.
While Marc came with way how Moodle does it:
Michal, I showed this Moodle example because you wanted to know what other products are doing. I am not advocating for their mechanism.
About PMA_grabParameter(), is the second parameter used for the origin of the variable, like GET, POST, COOKIE, SESSION?
Comments?
// ifsetor() ;-) function checkRequest($name, $default = null) { if ( isset( $_REQUEST[$name] ) ) { return $_REQUEST[$name]; }
return $default;}
i think in most cases PMA should use $_REQUEST directly and use one of the above function only to set default values
using of $_REQUEST makes it more clear where this variable came from, reminding the developer always to take care with this variables!
I don't understand why using $_REQUEST makes more clear where this variable came from. In $_REQUEST, variables can come from EGPCS, as defined by the variables_order directive. I think that it's better to say explicitly where we expect each variable to come from.
and i think its not good to always 'clean' variables
what will you clean of? you can not decide what users inserts into her database or they name her tables and fields
We have many possible sources for an attack. An evident one is with the variables that are echoed back (partly checked with PMA_sanitize(), for example in sql.php. But there are other sources, like attacks on $_FILES.
you just have to take care to escape the input correctly before inserting or displaying - but not cleaning!
and if the variable is a choice of options you have to check against the original choices (in_array or array_key_exists)
Marc Delisle schrieb:
i think in most cases PMA should use $_REQUEST directly and use one of the above function only to set default values
using of $_REQUEST makes it more clear where this variable came from, reminding the developer always to take care with this variables!
I don't understand why using $_REQUEST makes more clear where this variable came from. In $_REQUEST, variables can come from EGPCS, as defined by the variables_order directive. I think that it's better to say explicitly where we expect each variable to come from.
$_REQUEST holds only $_POST, $_GET, $_COOKIE, normally in this order
and it makes clear that this variable came from outside and has to be handled with care, of course the other superglobals too
and i think its not good to always 'clean' variables
what will you clean of? you can not decide what users inserts into her database or they name her tables and fields
We have many possible sources for an attack. An evident one is with the variables that are echoed back (partly checked with PMA_sanitize(), for example in sql.php. But there are other sources, like attacks on $_FILES.
$_Files is only used in import or binary upload, in this rare places this Array should be handled explicitly
Sebastian Mendel a écrit :
Marc Delisle schrieb:
i think in most cases PMA should use $_REQUEST directly and use one of the above function only to set default values
using of $_REQUEST makes it more clear where this variable came from, reminding the developer always to take care with this variables!
I don't understand why using $_REQUEST makes more clear where this variable came from. In $_REQUEST, variables can come from EGPCS, as defined by the variables_order directive. I think that it's better to say explicitly where we expect each variable to come from.
$_REQUEST holds only $_POST, $_GET, $_COOKIE, normally in this order
Not according to http://www.php.net/manual/en/ini.core.php#ini.variables-order
and it makes clear that this variable came from outside and has to be handled with care, of course the other superglobals too
So why not go with the clearer way?
and i think its not good to always 'clean' variables
what will you clean of? you can not decide what users inserts into her database or they name her tables and fields
We have many possible sources for an attack. An evident one is with the variables that are echoed back (partly checked with PMA_sanitize(), for example in sql.php. But there are other sources, like attacks on $_FILES.
$_Files is only used in import or binary upload, in this rare places this Array should be handled explicitly
Ok.
Marc Delisle schrieb:
Sebastian Mendel a écrit :
Marc Delisle schrieb:
i think in most cases PMA should use $_REQUEST directly and use one of the above function only to set default values
using of $_REQUEST makes it more clear where this variable came from, reminding the developer always to take care with this variables!
I don't understand why using $_REQUEST makes more clear where this variable came from. In $_REQUEST, variables can come from EGPCS, as defined by the variables_order directive. I think that it's better to say explicitly where we expect each variable to come from.
$_REQUEST holds only $_POST, $_GET, $_COOKIE, normally in this order
Not according to http://www.php.net/manual/en/ini.core.php#ini.variables-order
this is the order for register_globals what has not much todo with $_REQUEST
http://de.php.net/manual/en/reserved.variables.php#reserved.variables.reques...
and it makes clear that this variable came from outside and has to be handled with care, of course the other superglobals too
So why not go with the clearer way?
why not? i did not fully understand ... what is the clearer way?
i prefer using $_REQUEST as the clearer way as i wrote before
i always prefer using superglobals than importing them into GLOBAL space
and i prefer use $_REQUEST than $_POST or $_GET as sometimes its needed to change between POSTING or 'GETTING' variables, like PMA currently does with request larger than 1000 chars.
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Sebastian Mendel a écrit :
Marc Delisle schrieb:
i think in most cases PMA should use $_REQUEST directly and use one of the above function only to set default values
using of $_REQUEST makes it more clear where this variable came from, reminding the developer always to take care with this variables!
I don't understand why using $_REQUEST makes more clear where this variable came from. In $_REQUEST, variables can come from EGPCS, as defined by the variables_order directive. I think that it's better to say explicitly where we expect each variable to come from.
$_REQUEST holds only $_POST, $_GET, $_COOKIE, normally in this order
Not according to http://www.php.net/manual/en/ini.core.php#ini.variables-order
this is the order for register_globals what has not much todo with $_REQUEST
From the manual: "$_REQUEST
Variables provided to the script via the GET, POST, and COOKIE input mechanisms, and which therefore cannot be trusted. The presence and order of variable inclusion in this array is defined according to the PHP variables_order configuration directive. "
http://de.php.net/manual/en/reserved.variables.php#reserved.variables.reques...
and it makes clear that this variable came from outside and has to be handled with care, of course the other superglobals too
So why not go with the clearer way?
why not? i did not fully understand ... what is the clearer way?
i prefer using $_REQUEST as the clearer way as i wrote before
i always prefer using superglobals than importing them into GLOBAL space
This is a separate discussion. So you would like to refer to $_REQUEST['foo'] everywhere in the code, instead of importing into a global $foo?
and i prefer use $_REQUEST than $_POST or $_GET as sometimes its needed to change between POSTING or 'GETTING' variables, like PMA currently does with request larger than 1000 chars.
I just wonder, since the contents of $_REQUEST _might_ be coming from Environment, Server and Cookie, depending on the variables_order directive, if we are not going to regret it later.
Marc
Hi
On Wed 7. 12. 2005 20:48, Marc Delisle wrote:
From the manual: "$_REQUEST
Variables provided to the script via the GET, POST, and COOKIEinput mechanisms, and which therefore cannot be trusted. The presence and order of variable inclusion in this array is defined according to the PHP variables_order configuration directive. "
Yes, so there are variables from GET, POST, and COOKIE and their preference is defined by variables_order.
This is a separate discussion. So you would like to refer to $_REQUEST['foo'] everywhere in the code, instead of importing into a global $foo?
Yes. You can then perfectly see that this variable is potentially dangerous. Putting everything in global namespace hides this difference.
Michal Čihař a écrit :
Hi
On Wed 7. 12. 2005 20:48, Marc Delisle wrote:
From the manual: "$_REQUEST
Variables provided to the script via the GET, POST, and COOKIEinput mechanisms, and which therefore cannot be trusted. The presence and order of variable inclusion in this array is defined according to the PHP variables_order configuration directive. "
Yes, so there are variables from GET, POST, and COOKIE and their preference is defined by variables_order.
This is a separate discussion. So you would like to refer to $_REQUEST['foo'] everywhere in the code, instead of importing into a global $foo?
Yes. You can then perfectly see that this variable is potentially dangerous. Putting everything in global namespace hides this difference.
Ok I agree.
Another point: having a look at $GLOBALS, can we put all strSomething messages somewhere else? I'm afraid that we don't have a choice. Maybe they could be in a cute array under $GLOBALS but this produces much recoding everywhere.
Marc Delisle schrieb:
Another point: having a look at $GLOBALS, can we put all strSomething messages somewhere else? I'm afraid that we don't have a choice. Maybe they could be in a cute array under $GLOBALS but this produces much recoding everywhere.
i also thought about this, possible in a first step we can make a function
PMA_str($string[, argument[, ...]]) { $args = func_get_args(); if ( isset( GLOBALS['str' . $args[0]] ) { $args[0] = GLOBALS['str' . $args[0]]; return call_user_func_array('sprintf', func_get_args()); } return ucword(strtolower(str_replace('_', ' ', $string))); }
Hi
On Wed, 07 Dec 2005 19:17:16 -0500 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
Another point: having a look at $GLOBALS, can we put all strSomething messages somewhere else? I'm afraid that we don't have a choice. Maybe they could be in a cute array under $GLOBALS but this produces much recoding everywhere.
I thing automatically replacing most of occurrences (I guess that all except composed ones like used in server status) should not be a problem. I volunteer to do this if we decide to make some change.
Hi!
I thing automatically replacing most of occurrences (I guess that all except composed ones like used in server status) should not be a problem. I volunteer to do this if we decide to make some change.
How about using constants? They cannot be injected by users, and we would just need to search + replace $strXXX with strXXX. AFAIK constants don't perform slower than variables, possibly even faster because they can be cached by ByteOP caches [at least I remember having heard that].
Using a function like Sebastian proposed (PMA_str()) would perform terribly slow, when used a couple of times within the page, since getting functions arguments, doing str_replace, calling another user space function etc. would really take up many cycles.
Regards, Garvin
Garvin Hicking a écrit :
Hi!
I thing automatically replacing most of occurrences (I guess that all except composed ones like used in server status) should not be a problem. I volunteer to do this if we decide to make some change.
How about using constants? They cannot be injected by users, and we would just need to search + replace $strXXX with strXXX. AFAIK constants don't perform slower than variables, possibly even faster because they can be cached by ByteOP caches [at least I remember having heard that].
Using a function like Sebastian proposed (PMA_str()) would perform terribly slow, when used a couple of times within the page, since getting functions arguments, doing str_replace, calling another user space function etc. would really take up many cycles.
Regards, Garvin
Indeed, constants look like the best choice, apart from the fact that translators will have to adapt.
Marc
Hi Marc!
Indeed, constants look like the best choice, apart from the fact that translators will have to adapt.
We could even create a simple PHP script that turns variables to constants. We could run that to turn old style translations into new files...
But I think it wouldn't make a change for translators. Especially if we adapt to the proposed Online translation system, from Michal... (to which I'm +1, but I think not much people might use it?)
Regards, Garvin
Marc Delisle schrieb:
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Sebastian Mendel a écrit :
Marc Delisle schrieb:
i think in most cases PMA should use $_REQUEST directly and use one of the above function only to set default values
using of $_REQUEST makes it more clear where this variable came from, reminding the developer always to take care with this variables!
I don't understand why using $_REQUEST makes more clear where this variable came from. In $_REQUEST, variables can come from EGPCS, as defined by the variables_order directive. I think that it's better to say explicitly where we expect each variable to come from.
$_REQUEST holds only $_POST, $_GET, $_COOKIE, normally in this order
Not according to http://www.php.net/manual/en/ini.core.php#ini.variables-order
this is the order for register_globals what has not much todo with $_REQUEST
From the manual: "$_REQUEST
Variables provided to the script via the GET, POST, and COOKIE inputmechanisms, and which therefore cannot be trusted. The presence and order of variable inclusion in this array is defined according to the PHP variables_order configuration directive. "
yes as it reads ONLY GET, POST, and COOKIE variables_order defines ONLY the ORDER how this three superglobals are merged into $_REQUEST
AND variables_order defines WHAT super_gloabls are filled
f.e. with variables_order = 'C';
only $_COOKIE is filled and $_GET, $_POST, $_ENV, $_SERVER is empty
with variables_order = 'GPCES'; all superglobals are filled
but $_REQUEST allways only holds the content of $_GET, $_POST, $_COOKIE
what leads to another problem with the default of 'GPCS' $_ENV is always empty but sometimes used in PMA ...
and it makes clear that this variable came from outside and has to be handled with care, of course the other superglobals too
So why not go with the clearer way?
why not? i did not fully understand ... what is the clearer way?
i prefer using $_REQUEST as the clearer way as i wrote before
i always prefer using superglobals than importing them into GLOBAL space
This is a separate discussion. So you would like to refer to $_REQUEST['foo'] everywhere in the code, instead of importing into a global $foo?
yes, but normally this variables should only used once, when passing to the function/object who uses this variable ... moving PMA from preocedural to object oriented or at least more 'functionized'
and i prefer use $_REQUEST than $_POST or $_GET as sometimes its needed to change between POSTING or 'GETTING' variables, like PMA currently does with request larger than 1000 chars.
I just wonder, since the contents of $_REQUEST _might_ be coming from Environment, Server and Cookie, depending on the variables_order directive, if we are not going to regret it later.
no, only from GET, POST, COOKIE
just try print_r( $_REQUEST ) you will see no variables from $_SERVER or $_ENV
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Sebastian Mendel a écrit :
Marc Delisle schrieb:
> i think in most cases PMA should use $_REQUEST directly and use > one of the above function only to set default values > > using of $_REQUEST makes it more clear where this variable came > from, reminding the developer always to take care with this > variables!
I don't understand why using $_REQUEST makes more clear where this variable came from. In $_REQUEST, variables can come from EGPCS, as defined by the variables_order directive. I think that it's better to say explicitly where we expect each variable to come from.
$_REQUEST holds only $_POST, $_GET, $_COOKIE, normally in this order
Not according to http://www.php.net/manual/en/ini.core.php#ini.variables-order
this is the order for register_globals what has not much todo with $_REQUEST
From the manual: "$_REQUEST
Variables provided to the script via the GET, POST, and COOKIEinput mechanisms, and which therefore cannot be trusted. The presence and order of variable inclusion in this array is defined according to the PHP variables_order configuration directive. "
yes as it reads ONLY GET, POST, and COOKIE variables_order defines ONLY the ORDER how this three superglobals are merged into $_REQUEST
Ok I understand now.
AND variables_order defines WHAT super_gloabls are filled
f.e. with variables_order = 'C';
only $_COOKIE is filled and $_GET, $_POST, $_ENV, $_SERVER is empty
with variables_order = 'GPCES'; all superglobals are filled
but $_REQUEST allways only holds the content of $_GET, $_POST, $_COOKIE
what leads to another problem with the default of 'GPCS' $_ENV is always empty but sometimes used in PMA ...
Hmmm let's remember this...
and it makes clear that this variable came from outside and has to be handled with care, of course the other superglobals too
So why not go with the clearer way?
why not? i did not fully understand ... what is the clearer way?
i prefer using $_REQUEST as the clearer way as i wrote before
i always prefer using superglobals than importing them into GLOBAL space
This is a separate discussion. So you would like to refer to $_REQUEST['foo'] everywhere in the code, instead of importing into a global $foo?
yes, but normally this variables should only used once, when passing to the function/object who uses this variable ... moving PMA from preocedural to object oriented or at least more 'functionized'
and i prefer use $_REQUEST than $_POST or $_GET as sometimes its needed to change between POSTING or 'GETTING' variables, like PMA currently does with request larger than 1000 chars.
I just wonder, since the contents of $_REQUEST _might_ be coming from Environment, Server and Cookie, depending on the variables_order directive, if we are not going to regret it later.
no, only from GET, POST, COOKIE
just try print_r( $_REQUEST ) you will see no variables from $_SERVER or $_ENV
Marc Delisle schrieb:
f.e. with variables_order = 'C';
only $_COOKIE is filled and $_GET, $_POST, $_ENV, $_SERVER is empty
with variables_order = 'GPCES'; all superglobals are filled
but $_REQUEST allways only holds the content of $_GET, $_POST, $_COOKIE
what leads to another problem with the default of 'GPCS' $_ENV is always empty but sometimes used in PMA ...
Hmmm let's remember this...
does anyone knows how to get environment variables/settings if 'E' is missing in variables_order?
Hi
On Wed, 07 Dec 2005 22:58:39 +0100 Sebastian Mendel lists@sebastianmendel.de wrote:
does anyone knows how to get environment variables/settings if 'E' is missing in variables_order?
Does not getenv work in this situation?
Michal Čihař a écrit :
Hi
On Wed, 07 Dec 2005 22:58:39 +0100 Sebastian Mendel lists@sebastianmendel.de wrote:
does anyone knows how to get environment variables/settings if 'E' is missing in variables_order?
Does not getenv work in this situation?
Yes, I just tested it. When 'E' is missing, $_ENV['foo'] is undefined but getenv('foo') returns the correct environment value.
Marc
Hi
On Wed, 07 Dec 2005 10:06:41 -0500 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
Sebastian Mendel a écrit :
Michal Čihař schrieb:
I suggested to create some function like:
PMA_grabParameter($name, $request, $sanitizing = 'none', $required = TRUE)
The request parameter might not be needed, but it's up to discussion.
While Marc came with way how Moodle does it:
Michal, I showed this Moodle example because you wanted to know what other products are doing. I am not advocating for their mechanism.
About PMA_grabParameter(), is the second parameter used for the origin of the variable, like GET, POST, COOKIE, SESSION?
It was original purpose.
Comments?
// ifsetor() ;-) function checkRequest($name, $default = null) { if ( isset( $_REQUEST[$name] ) ) { return $_REQUEST[$name]; }
return $default;}
i think in most cases PMA should use $_REQUEST directly and use one of the above function only to set default values
using of $_REQUEST makes it more clear where this variable came from, reminding the developer always to take care with this variables!
I don't understand why using $_REQUEST makes more clear where this variable came from. In $_REQUEST, variables can come from EGPCS, as defined by the variables_order directive. I think that it's better to say explicitly where we expect each variable to come from.
Many variables can come at least either from POST or GET (see PMA_linkOrButton [or what's it's name]).
Michal Čihař a écrit :
Hi
On Wed, 07 Dec 2005 10:06:41 -0500 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
Sebastian Mendel a écrit :
Michal Čihař schrieb:
I suggested to create some function like:
PMA_grabParameter($name, $request, $sanitizing = 'none', $required = TRUE)
The request parameter might not be needed, but it's up to discussion.
While Marc came with way how Moodle does it:
Michal, I showed this Moodle example because you wanted to know what other products are doing. I am not advocating for their mechanism.
About PMA_grabParameter(), is the second parameter used for the origin of the variable, like GET, POST, COOKIE, SESSION?
It was original purpose.
Comments?
// ifsetor() ;-) function checkRequest($name, $default = null) { if ( isset( $_REQUEST[$name] ) ) { return $_REQUEST[$name]; }
return $default; }
i think in most cases PMA should use $_REQUEST directly and use one of the above function only to set default values
using of $_REQUEST makes it more clear where this variable came from, reminding the developer always to take care with this variables!
I don't understand why using $_REQUEST makes more clear where this variable came from. In $_REQUEST, variables can come from EGPCS, as defined by the variables_order directive. I think that it's better to say explicitly where we expect each variable to come from.
Many variables can come at least either from POST or GET (see PMA_linkOrButton [or what's it's name]).
Yes, we would have to mention all the possible sources. But I don't want to argue ad vitam aeternam about this :) If you all prefer using $_REQUEST, let's do it.
FYI, look what the Mambo team has done in their globals.php script. They are populating $GLOBALS. Not sure I approve their method. Comments?
----------- $raw = phpversion(); list($v_Upper,$v_Major,$v_Minor) = explode(".",$raw);
if (($v_Upper == 4 && $v_Major < 1) || $v_Upper < 4) { $_FILES = $HTTP_POST_FILES; $_ENV = $HTTP_ENV_VARS; $_GET = $HTTP_GET_VARS; $_POST = $HTTP_POST_VARS; $_COOKIE = $HTTP_COOKIE_VARS; $_SERVER = $HTTP_SERVER_VARS; $_SESSION = $HTTP_SESSION_VARS; $_FILES = $HTTP_POST_FILES; }
if (!ini_get('register_globals')) { while(list($key,$value)=each($_FILES)) $GLOBALS[$key]=$value; while(list($key,$value)=each($_ENV)) $GLOBALS[$key]=$value; while(list($key,$value)=each($_GET)) $GLOBALS[$key]=$value; while(list($key,$value)=each($_POST)) $GLOBALS[$key]=$value; while(list($key,$value)=each($_COOKIE)) $GLOBALS[$key]=$value; while(list($key,$value)=each($_SERVER)) $GLOBALS[$key]=$value; while(list($key,$value)=@each($_SESSION)) $GLOBALS[$key]=$value; foreach($_FILES as $key => $value){ $GLOBALS[$key]=$_FILES[$key]['tmp_name']; foreach($value as $ext => $value2){ $key2 = $key . '_' . $ext; $GLOBALS[$key2] = $value2; } } } ===============
Marc Delisle schrieb:
FYI, look what the Mambo team has done in their globals.php script. They are populating $GLOBALS. Not sure I approve their method. Comments?
btw. what exactly means FYI?
$raw = phpversion(); list($v_Upper,$v_Major,$v_Minor) = explode(".",$raw);
if (($v_Upper == 4 && $v_Major < 1) || $v_Upper < 4) { $_FILES = $HTTP_POST_FILES; $_ENV = $HTTP_ENV_VARS; $_GET = $HTTP_GET_VARS; $_POST = $HTTP_POST_VARS; $_COOKIE = $HTTP_COOKIE_VARS; $_SERVER = $HTTP_SERVER_VARS; $_SESSION = $HTTP_SESSION_VARS; $_FILES = $HTTP_POST_FILES; }
this is not reqired for PMA as, IMHO, pma does not run on PHP < 4.1 (like the documentation read)
if (!ini_get('register_globals')) { while(list($key,$value)=each($_FILES)) $GLOBALS[$key]=$value; while(list($key,$value)=each($_ENV)) $GLOBALS[$key]=$value; while(list($key,$value)=each($_GET)) $GLOBALS[$key]=$value; while(list($key,$value)=each($_POST)) $GLOBALS[$key]=$value; while(list($key,$value)=each($_COOKIE)) $GLOBALS[$key]=$value; while(list($key,$value)=each($_SERVER)) $GLOBALS[$key]=$value; while(list($key,$value)=@each($_SESSION)) $GLOBALS[$key]=$value; foreach($_FILES as $key => $value){ $GLOBALS[$key]=$_FILES[$key]['tmp_name']; foreach($value as $ext => $value2){ $key2 = $key . '_' . $ext; $GLOBALS[$key2] = $value2; } } }
they emulate register_globals! this is nto what we want to do? as this is what we are currently doing! not exactly ...
Sebastian Mendel a écrit :
Marc Delisle schrieb:
FYI, look what the Mambo team has done in their globals.php script. They are populating $GLOBALS. Not sure I approve their method. Comments?
btw. what exactly means FYI?
For Your Information
$raw = phpversion(); list($v_Upper,$v_Major,$v_Minor) = explode(".",$raw);
if (($v_Upper == 4 && $v_Major < 1) || $v_Upper < 4) { $_FILES = $HTTP_POST_FILES; $_ENV = $HTTP_ENV_VARS; $_GET = $HTTP_GET_VARS; $_POST = $HTTP_POST_VARS; $_COOKIE = $HTTP_COOKIE_VARS; $_SERVER = $HTTP_SERVER_VARS; $_SESSION = $HTTP_SESSION_VARS; $_FILES = $HTTP_POST_FILES; }
this is not reqired for PMA as, IMHO, pma does not run on PHP < 4.1 (like the documentation read)
if (!ini_get('register_globals')) { while(list($key,$value)=each($_FILES)) $GLOBALS[$key]=$value; while(list($key,$value)=each($_ENV)) $GLOBALS[$key]=$value; while(list($key,$value)=each($_GET)) $GLOBALS[$key]=$value; while(list($key,$value)=each($_POST)) $GLOBALS[$key]=$value; while(list($key,$value)=each($_COOKIE)) $GLOBALS[$key]=$value; while(list($key,$value)=each($_SERVER)) $GLOBALS[$key]=$value; while(list($key,$value)=@each($_SESSION)) $GLOBALS[$key]=$value; foreach($_FILES as $key => $value){ $GLOBALS[$key]=$_FILES[$key]['tmp_name']; foreach($value as $ext => $value2){ $key2 = $key . '_' . $ext; $GLOBALS[$key2] = $value2; } } }
they emulate register_globals! this is nto what we want to do? as this is what we are currently doing! not exactly ...
You're right, this is not what we want to do. Marc
-
Garvin Hicking -
Marc Delisle -
Michal Čihař -
Sebastian Mendel