(PHP 4 >= 4.1.0, PHP 5 < 5.4.0)
import_request_variables — Import GET/POST/Cookie variables into the global scope
$types
[, string $prefix
] )Imports GET/POST/Cookie variables into the global scope. It is useful if you disabled register_globals, but would like to see some variables in the global scope.
If you're interested in importing other variables into the global scope, such as $_SERVER, consider using extract().
This function has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0.
types
Using the types parameter, you can specify
which request variables to import. You can use 'G', 'P' and 'C'
characters respectively for GET, POST and Cookie. These characters are
not case sensitive, so you can also use any combination of 'g', 'p'
and 'c'. POST includes the POST uploaded file information.
Note:
Note that the order of the letters matters, as when using "GP", the POST variables will overwrite GET variables with the same name. Any other letters than GPC are discarded.
prefixVariable name prefix, prepended before all variable's name imported into the global scope. So if you have a GET value named "userid", and provide a prefix "pref_", then you'll get a global variable named $pref_userid.
Note:
Although the
prefixparameter is optional, you will get anE_NOTICElevel error if you specify no prefix, or specify an empty string as a prefix. This is a possible security hazard. Notice level errors are not displayed using the default error reporting level.
Returns TRUE on success or FALSE on failure.
Example #1 import_request_variables() example
<?php
// This will import GET and POST vars
// with an "rvar_" prefix
import_request_variables("gp", "rvar_");
echo $rvar_foo;
?>
Call me crazy, but it seems to me that if you use this function, even WITH the prefix, then you might as well just turn register_globals back on...
Sooner or later, somebody will find a "hole" with your prefixed variables in an un-initialized variable.
Better to import precisely the variables you need, and initialize anything else properly.
import_request_variables() is gone from PHP since version 5.4.0. A simple plug-in replacement it extract().
For example:
import_request_variables('gp', 'v_');
Can be replaced with:
extract($_REQUEST, EXTR_PREFIX_ALL|EXTR_REFS, 'v');
oops, a typo in my comment:
The last line in the second example (the on using the extract() function) should read:
echo $_GET['var']; # prints 1, so $_GET has been unchanged
What i do is have a small script in my header file that takes an array called $input, and loops through the array to extract variables. that way the security hole can be closed, as you specify what variables you would like extracted
$input = array('name' => null, 'age' => 26) ;
// 26 is the default age, if $_GET['age'] is empty or not set
function extract_get()
{
global $input ;
if ($input)
{
foreach ($input as $k => $v)
{
if ($_GET[$k] == '' or $_GET[$k] == NULL)
{
$GLOBALS[$k] = $v ;
}
else
{
$GLOBALS = $_GET[$k] ;
}
}
}
}
reply to ceo AT l-i-e DOT com:
I don't think it's a risk, as all of your request variables will be tagged with the prefix. As long as you don't prefix any of your internal variables with the same, you should be fine.
If someone tries to access an uninitiated security-related variable like $admin_level through request data, it will get imported as $RV_admin_level.
import_request_variables does *not* read from the $_GET, $_POST, or $_COOKIE arrays - it reads the data directly from what was submitted. This is an important distinction if, for example, the server has magic_quotes turned on and you massage the data to run stripslashes on it; if you then use import_request_variables, your variables will still have slashes in them.
In other words: even if you say $_GET=""; $_POST=""; then use import_request_variables, it'll still get all the request data.
If you change the contents of $_GET and you then want to bring this data into global variables, use extract($_GET, EXTR_PREFIX_ALL, "myprefix") instead.
