PHP Register_Globals

[sub-spaced]

Hi Everyone,

I have a slight problem with my current version of PHP, the register_globals is set to off and I do not know how to change it to on. I do not know Unix commands and for some reason the php.ini file is in not in the usr/local directory but in etc/ directory and is named php.ini.default.
Can anybody help me, I can't find anything on the internet on how to change the file with the unix commands.

Please help.

Thanks
Darren

 

[Gnomo]

I've had similar problems trying to set the include path. I tried renaming the php.ini.default to php.ini ... didn't work. I tried editing the php.ini.default file ... didn't work. Finally I did find that you can change ini settings at runtime.

So, while it isn't a solution, you might be able to use the ini_set('register_globals', TRUE) as a work around until someone else can give us both the answer.

 

[uoba]

First of all. Do a test PHP file from your server with just this code in (you may know this, you may not):

<?php phpinfo(); ?>

Save the file on your web server and open it from your browser. It'll tell you all the info about your PHP install. The sixth row down should tell you where your php.ini file resides on your machine.

Let me know if it's there and whether you've found it. We can take it from there.

 

[btoth]

If the php.ini file is not located in the directory specified, you can copy and move the php.ini.default file and rename in php.ini and it will look for that file instead if I'm remembering correctly. Then you can just Go>Go To Folder... and open it from there to edit it with a proper text editor if you're not comfortable with the Unix terminal.

If I'm wrong about the ini thing, someone correct me.

My php.ini.default is located in /etc and I made a php.ini in /etc also that has my custom settings and is verified using the <?php phpinfo(); ?> function.

 

[uoba]

Yep, this is fine to do (I think this is the purpose of the php.ini.default file anyway).

 

[octane]

Before I begin, remember the old adage: do as I say and not as I do .. 'cause I don't do!

To get around the register_globals malarky, you now have to request the data from the GET/POST with $newVar = $_GET['varname'] or $_POST['varname']. This is because they want to save memory so not every single thing posted is automatically stored in a variable.

Also, doing things this way is inherently more secure than the old way .. don't know how, but just is, OK!

I've got _way_ too many lines of code to audit and I'm still having problems getting things to work that way...

 

[andehlu]

Also, doing things this way is inherently more secure than the old way .. don't know how, but just is, OK!

It ensures that variables are being passed via thier proper action and not just some wanker plugging URL vars trying to use GET to execute your scripts...

 

[octane]

It ensures that variables are being passed via thier proper action and not just some wanker plugging URL vars trying to use GET to execute your scripts...

Ooh! Get him?

I knew it was something like that, but I'm not all that interested in _how_ php chooses to do it's thang, so long as it does it in a timely fashion...

 

[dlloyd]

To clarify: turning registar_globals to OFF means that you can put anything you like after the URL, but unless you retrieve it with a $_GET['']; it doesn't get executed into the script.
If registar_globals is ON, then anything after the URL is automatically included. For example, some idiot could try to poison your MySQL query by putting something like index.php?query=[insert something here], assuming your MySQL query was contained in a variable called $query. The danger is that this idiot could go and download an open source program you were using and know all the possible variables he could poison.