register_globals On

[rip_curl]

Hello
how can I make register_globals On for individual user? I don't want to switch it on on server.

[kernow]

Go to the directory where your clients php scripts are. Then create a new file called php.ini
Then edit that file and put this line in it:
register_globals = On

[AndyReed]

how can I make register_globals On for individual user? I don't want to switch it on on server.

For security purposes, some people might disagree with me, but if I were you, I wouldn't switch register_globals ON. I'll keep them OFF.

To learn more about register_globals, to share your thoughts and read others comments, go to: http://us3.php.net/register_globals

[webignition]

I'd agree with Andy here - for security reasons, it is strongly advisable to keep register_globals off, even if a client wants it turned on.

If the answer is to turn register_globals on, you're asking the wrong questions. To be more specific, alternative solutions exist and one that reduces security should not be considered.

[Radio_Head]

Anyone knows which are the security problems of register_globals on when safe_mode is on ?

In each case I don't think very useful to turn off register_globals off because it can be set to on using .htaccess .

(the good point is that php 6 has deprecated register_globals on from source code ,
so with php6 register_globals will be definitely off)

[jackie46]

I'd agree with Andy here - for security reasons, it is strongly advisable to keep register_globals off, even if a client wants it turned on.

If the answer is to turn register_globals on, you're asking the wrong questions. To be more specific, alternative solutions exist and one that reduces security should not be considered.

You may agree with Andy Reed but that depends on your user needs, whether you have phpsuexec installed or if your running Fantastico in which case haveing register globals OFF is not an option. Mediocure hosts that do nothing but host .html pages can get by with this setting being OFF. Competative hosts such as what we have would find users screaming and moving elsewhere to get what they want in order to be able to run their applications. In our case, this is not an option to have it OFF.

Pats on the back to Andy Reed. I completely disagree with his suggestion. Of course it makes the box more secure and there is no denying that, but thats beside the point. We want to make our users happy and there are other avenues to follow in making sure that your box is not compromised.

[webignition]

Competative hosts such as what we have would find users screaming and moving elsewhere to get what they want in order to be able to run their applications. In our case, this is not an option to have it OFF..

Only because users don't understand or don't care about the security issues related to having register_globals on. And if you think that turning register_globals on just because a user insists then you don't understand the issues either.

register_globals really does nothing much more than allow $_POST['postvar'] and $_GET['getvar'] to be accessed directly as $postvar and $getvar without having to first declare or define them. This is something that can easily be worked around or simulated.

register_globals never needs to be on. Simply replacing all instances of $postvar with $_POST['postvar'] and $getvar with $_GET['getvar'] would sort things out.

If this is really too much of a problem, the following code will register_globalify $_POST and $_GET:

foreach($_POST AS $key => $value) { ${$key} = $value; }
foreach($_GET AS $key => $value) { ${$key} = $value; }

Furthermore, register_globals will no longer be an option as of PHP6. Rather than panic over it when the time arises, it's just better to phase it out now.

On a more positive note (after re-reading my post it might seem a little harsh, which is not my intent), if a user insists on having register_globals turned on, explain the security-based reasons why this is not an option and put forward alternatives for working around the problem or simulating the behaviour of register_globals. If you have to, be blunt and point out that they can have security and reliability or a given script and ask them what they consider to be more important.

I also try my best, when possible, to find patches and/or newer versions of scripts that are no longer dependent on register_globals. A patch exists for oscommerce, for example. Users that insist that register_globals is turned on are, admittedly, not happy that I won't allow it however the fact that I will do as much as possible to make things work with register_globals turned off seems to alleviate any unhappiness.

I would also find it hard to trust in the abilities of a PHP developer if they insisted that either their script must have register_globals on to function or insist that it is impossible to change the script so that it is no longer dependent on register_globals. It's not that tricky and any competent developer would have no problems.

[AndyReed]

Only because users don't understand or don't care about the security issues related to having register_globals on. And if you think that turning register_globals on just because a user insists then you don't understand the issues either.

Very well said, webignition.

[apodigm]

This is nice discussion. I understand the philosophy debate and the declarations from PHP about register_globals.

Regardless, I would still like an answer to the original question. I have a single customer who has an application that will be time consuming to upgrade. While the patches are installed, I would like to "buy some time" by allowing register globals on only that one single account - without allowing them on the server-wide php.ini.

I'm running php 4.3.3 and php 5.1.4 with phpsuexec. I've noticed the php_flag arguments in .htaccess do not work. And I've tried putting the php.ini file in the hosting directory and that also does not work. php_admin_flag in the httpd.conf configuration for the virtual host also does not work.

Can someone explain what I am missing or how to implement register_globals on a single account in the phpsuexec environment?

[nat]

Just upgraded to PHP Version 5.1.4 with phpsuexec and placing register_globals = On in a php.ini file is no longer turning it on.

A phpinfo file in the same directory as the php.ini file still shows it off for both the local value and master value.

Can some with 5.1.4 phpsuexec try it for a second to see if it works or if i'm nuts.

[Mysteerie]

Just upgraded to PHP Version 5.1.4 with phpsuexec and placing register_globals = On in a php.ini file is no longer turning it on.

A phpinfo file in the same directory as the php.ini file still shows it off for both the local value and master value.

Can some with 5.1.4 phpsuexec try it for a second to see if it works or if i'm nuts.

Yes, I have the same problem.

[Secret Agent]

Same here, how do we use register globals on in htaccess when phpsuexec support is enabled?

[XPerties]

Same issue here. Anyone have a fix or work around?

[webignition]

I still think that enabling register_globals just to get a script working is about as sensible as replacing the wheels on your car with large round cheeses just to get your sound system to work.

Surely if people chose not to use large round cheeses on their axles, companies would soon stop developing sound systems dependent on such large round cheeses.

[XPerties]

I still think that enabling register_globals just to get a script working is about as sensible as replacing the wheels on your car with large round cheeses just to get your sound system to work.

Surely if people chose not to use large round cheeses on their axles, companies would soon stop developing sound systems dependent on such large round cheeses.

Since you seem to be full of wisdom (and humor if I might add) could you enlighten me with your vocal point when dealing with multiple clients regarding their scripts and not working?