|
|
|||||||||
|
|||||||||
|
|||||||||
| |||||||||
![]() |
|
|
«
Previous Thread
|
Next Thread
»
|
Thread Tools | Search this Thread | Display Modes |
|
|
|
Free Web 2.0 Code Generator! Generate data entry and reporting .NET Web apps in minutes. Quickly create visually stunning, feature-rich apps that are easy to customize and ready to deploy. Download Now!
|
|
#1
|
|||
|
|||
|
Register Globals (How It Works)
I've realized that way too many PHP developers just don't understand the register_globals setting.
Here are some notes ( I didn't feel an official article was necessary, so this will have to do ): 1. You can turn on/off register_globals from PHP.INI, .htaccess and httpd.conf using php_value directive, php_flag 2. You can't set register_globals on/off during runtime 3. $_GET, $_POST, $_SESSION, $_COOKIE, etc are called superglobals and are globally accessible. (yes, even from functions). 4. $HTTP_GET_VARS, $HTTP_POST_VARS, etc are predefined variables like the superglobals, yet these are not in the same namespace nor are they globally accessible. 5. Using $varname instead of $_GET['varname'] or $_POST['varname'] can potentially be dangerous to your scripts... but that depends on how you are using them. It isn't necessarily the end of the world if you do, but I suggest you don't. Not just for security, but for compatible, portable, and clean code. Take a look at a sample I put together just for all those who need a quick pointer in the right direction: http://www.laidbak.net/phpsample/reg_globals/ In the example you will find two links. Both are just a list of variables from the $_GET and $HTTP_GET_VARS array's which PHP has predefined at runtime. One is in a directory where register_globals is turned off, and the other has register_globals on. Take a look at all the variables, but definately make note of the var_dumps that are highlighted with color. You will notice that there are multiple ways to access this info. This example helped me to clarify a while ago that using the superglobal array's is a much cleaner way to program in PHP. It was either take the manual's word for it or test it out myself.
__________________
__________________________________________________ _ Wil Moore III, MCP | Integrations Specialist | Senior Consultant Are You Listed...? | DigitallySmooth Inc. |
|
#2
|
|||
|
|||
|
Sticky!
This post is worthy of a Sticky! It will help newcomers familiarize themselves with the superglobal arrays.
If anyone has any other tips they feel would merit this discussion (not necessarily related to superglobals), feel free to post! Helping others improves everyone's skillset, including your own!
__________________
____________________________________________ Developer Shed Weekly Writer | DevArticles Forum Moderator Build Your Own KlipFolio Klip With PHP FrankManno.com - Under Construction Design Interactive Group - Under Construction |
|
#3
|
||||
|
||||
|
Re: Register Globals (How It Works)
Quote:
You forgot $_SERVER, $_FILES, $_ENV, and $_REQUEST Here's a good link that has examples of all of the superglobals http://www.php.net/variables.predefined |
|
#4
|
|||
|
|||
|
stupid question!
do the super globals also work when register_globals is off. so is it good practice to always use them. I think that is what will was saying but i just want to make sure. thanks dave |
|
#5
|
|||
|
|||
|
Yes, when register_globals is off you have the superglobal ($_GET, $_POST) and the "old" server variable ($HTTP_GET_VARS, $HTTP_POST_VARS) arrays.
The only thing you don't get with register_globals turned off, are automatically extracted variables coming in from GET and POST. (e.g. $_POST[userid] doesn't automatically show up as $userid. And this is a good thing, because you want to control where such variables can come from. Sure, register_globals sounds convenient, but it comes at a price. A simplistic example: With register_globals it's possible that a hacker could access your restricted area by injecting variables through the URL. If your script checks for the existence of variables without knowing where they come from, that could mean trouble. For example, accessing yoursite/restricted.php?loggedin=1 would lead to a variable called $loggedin existing in the script. Simply checking if ($loggedin) would be a poor safeguard. |
|
#6
|
|||
|
|||
|
And if you wanto extract the variables even when register_globals is off, you can use SafeExtract()
HTH! |
|
#7
|
|||
|
|||
|
Great post, laidbak! I wish I had seen it about 4 weeks ago
![]() |
|
#8
|
|||
|
|||
|
Yeah, I know how that goes... I've struggled through many issues before realizing I could have just looked up the answer.
Too bad the answer is never available when you are looking for it though. |
|
#9
|
|||
|
|||
|
Hey Wil,
Nice work your post definetly sheds light on the globals in PHP. Personally, I think that they've just confused everyone by adding the $_XXX variables and depreciating the $HTTP_POST_VARS (for example) array.Anyway, just 1 thing that no one has mentioned. For those of you working with older scripts, or trying to run with register_globals off on a newever version of PHP (such as 4.3), you need to declare the older arrays as global if the scope you're using is a function, such as: <?php function test() { global $HTTP_GET_VARS; $x = $HTTP_GET_VARS["x"]; echo $x; } test(); ?> Make sure you add the "global..." line. This stands true for any of the depreciated arrays such as $HTTP_POST_VARS, $HTTP_SERVER_VARS, etc... |
|
#10
|
|||
|
|||
|
Hey Mytch,
Thanks for the feedback. I should have included that... I guess I left it out because I tend to not use the global statement anywhere in my scripts. I just grepped a bunch of my code to see if I could really make that claim... yup, I haven't used it anywhere in anything I have on my box at the moment. Everything I do is without the use of declaring globals of any kind. A buddy of mine asked me recently how I would get the value of the server's root path into a function... My answer was: Code:
define('ROOT_DIRECTORY', $_SERVER['DOCUMENT_ROOT']);
function getRoot()
{
return ROOT_DIRECTORY;
}
print 'Root is : '.getRoot();
Thanks again Mytch... |
|
#11
|
|||
|
|||
|
in response to the code snipped above on getting the value of a server's root path - why not just:
print 'Root is : ' . $_SERVER['DOCUMENT_ROOT']; |
|
#12
|
|||
|
|||
|
The main point of the post was to show the scope of a defined constant.
|
|
#13
|
||||
|
||||
|
Just thought of something else I posted in another thread that probably goes well here too. Though I don't advocate this usage as a common practice, it could help get some people out of a jam. Imagine a scenario in which somebody has to change hosts, and the new host doesn't support register_globals=on, but the code's all written with variables unscoped. As a quick fix to get the site up and running until a code conversion can be done, the following code might come in handy:
PHP Code:
It loops through the $_POST array and, for each key, creates a variable whose name corresponds to that key, and assigns the associated value to the new variable. Again, I think it's important to scope your variables properly if only to make your code legible to other developers, but if you find yourself in a pinch, this might help you out in the short term. |
|
#14
|
|||
|
|||
|
In that case why not try:
PHP Code:
|
|
#15
|
|||
|
|||
|
This is a very helpful thread. thank you and good job
|
|
#16
|
|||
|