View Full Version : php.ini Question

Dec 11, 2003, 07:05 AM
I'm a novice web designer and I'm trying to turn on register_globals and I've tried what knowledge and what little I could find on the web for it...

Can someone please tell me how to turn ON register_globals for PHP?

PHP version - 4.3.4
Mac OS X 10.3.1

Thank you in advance.

Dec 11, 2003, 09:16 AM
you'll have to edit your php.ini file, found at: usr/local/lib/php.ini. however, you may not even have one; i believe the configuration is set at install, so there's no need for an .ini file by default.

if that's the case, just create a php.ini file in that directory with this line:register_globals = ON

word of warning, though: later versions of PHP ship with register_globals off for a good reason. if you don't need them turned on (which is to say, if you're not running a 3rd party package that absolutely requires them on) then you should consider leaving them off and coding around it. it's safer and more secure.

Dec 11, 2003, 10:34 AM
There is a php.ini file and I did try to edit the line for register_globals though it wouldn't still be on according to the phpinfo. I know it is off by default due to security though I'm trying a script found off of hotscripts.com that won't work with it off.

I'm beginning to reconsider turning it on if it is a security problem... though this is not a on commercial server, it is on a developing server for my own needs. What exact security issue are problematic if register_globals is on?

Also once the php.ini file is edited does apache need to be restarted? Does the whole machine need to be?

Dec 11, 2003, 11:29 AM
yeah, you'll need to restart apache for sure.

there's no "real" security problem if you're just running a local staging server -- it's not like anyone's going to get access to your scripts. but if your live server has register_globals on, it opens up your scripts to malicious access. (i'll explain that in a second.) if your staging server is not registering globals, you'll be forced to write safer code -- and when you do go live, you'll know that you've implemented at least one security measure.

now the technical stuff. let's say i'm passing a variable from a form:

<form action="process.php">
<input type="hidden" name="foo" value="something" />

with register_globals off, i'd need to extract $foo in my process.php script before i could work with it. what i'll do is define $foo as a variable that can only come from an http post method.

$foo = $_POST["foo"];

but if register_globals was on, $foo would automatically be recognized and i wouldn't have to define it as such. which is more convenient, but consider if some miscreant entered the following URL into their browser:


because i'm not ensuring that $foo is coming from a post, it's possible to spoof the variable and send it through a get method.

real life consequences: if you're not handling money or senitive data, probably nothing serious. still, it's better to make sure you know where your variables are coming from, just to make sure your scripts work the way you intend them to. you never know, someone might mis-type a URL or a search engine could feed your script an outdated URL with a paramater that is no longer accounted for.

Dec 11, 2003, 12:28 PM
Thanks for your explanation and insight on this issue! I appreciate your time. Currently I'm at work but as soon as I get home I will toy with it further. Thanks again.