By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,642 Members | 1,696 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,642 IT Pros & Developers. It's quick & easy.

Disabling global vars without php.ini access?

P: n/a
I've got a server where register_globals is on in php.ini, but its affecting
the way the website works. It was programmed with the assumption that it
would always be off, and i've always used the full names such as
$_SESSION['userid'] etc in all the code. However, I also use some local
variables of $userid, and on this server they seem to be changing the
session variable when I use them. I don't have access to php.ini, and its
on a Win2000 server so can't use htaccess. According to the documentation,
I can't set it at runtime with ini_set.

So, is there any way I can disable the operation of register globals /
superglobal variables in this situation? I really don't want to go through
and change all my variable names, since that is exactly why I made sure to
use the full variable name every time for sessions, post and get values.
Thanks

David
Jul 17 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
"David Walker" a écrit le 05/11/2003 :
I've got a server where register_globals is on in php.ini, but its affecting
the way the website works. It was programmed with the assumption that it
would always be off, and i've always used the full names such as
$_SESSION['userid'] etc in all the code. However, I also use some local
variables of $userid, and on this server they seem to be changing the
session variable when I use them. I don't have access to php.ini, and its
on a Win2000 server so can't use htaccess. According to the documentation,
I can't set it at runtime with ini_set.

So, is there any way I can disable the operation of register globals /
superglobal variables in this situation? I really don't want to go through
and change all my variable names, since that is exactly why I made sure to
use the full variable name every time for sessions, post and get values.
Thanks

David


Maybe you could try to browse through the $_POST, $_GET and $_COOKIE
vars and unset the correspondant var at the beginning of your scripts :

foreach( $_POST AS $key => $val )
{
unset $$key;
}

Without any warranty, not tried.
Jul 17 '05 #2

P: n/a
> Maybe you could try to browse through the $_POST, $_GET and $_COOKIE
vars and unset the correspondant var at the beginning of your scripts :

foreach( $_POST AS $key => $val )
{
unset $$key;
}


I still want to be able to access those variables though. For example, the
userid variable I have.

Pages on the site with restricted access check that value as a session
variable, as $_SESSION['userid'], but on a page like that I may be changing
someone elses details, for which I use the local variable $userid. I want
to be able to use both separately on the same page.
I'd hoped for another way to disable global_variables without php.ini
access.

David
Jul 17 '05 #3

P: n/a
David Walker wrote:
Maybe you could try to browse through the $_POST, $_GET and $_COOKIE
vars and unset the correspondant var at the beginning of your scripts :

foreach( $_POST AS $key => $val )
{
unset $$key;
}

I still want to be able to access those variables though. For example, the
userid variable I have.

Pages on the site with restricted access check that value as a session
variable, as $_SESSION['userid'], but on a page like that I may be changing
someone elses details, for which I use the local variable $userid. I want
to be able to use both separately on the same page.
I'd hoped for another way to disable global_variables without php.ini
access.

David


No, he didn't mean you unset them from the superglobal arrays, he meant
the CORRESPONDING variables (symbols).

ie.

foreach($_REQUEST as $varName => $varVal) unset($varName);

notice that $_REQUEST is *still populated*. $_REQUEST includes $_GET,
$_POST, $_COOKIE (GPC). You need another foreach statement to take care
of $_SESSION

foreach($_SESSION as $varName => $varVal) @unset($varName);

stick that (both lines) at the top of your pages.

Jul 17 '05 #4

P: n/a
"David Walker" <wb*********@hotmail.com> wrote in message news:<bo**********@wisteria.csv.warwick.ac.uk>...
I've got a server where register_globals is on in php.ini, but its affecting
the way the website works. It was programmed with the assumption that it
would always be off, and i've always used the full names such as
$_SESSION['userid'] etc in all the code. However, I also use some local
variables of $userid, and on this server they seem to be changing the
session variable when I use them.


Is it the problem that I reported once? (
http://bugs.php.net/bug.php?id=22389 )
---
"The world is too dangerous to live in—not because of the people who
do evil, but because of the people who sit and let it happen"---Albert
Einstein
Email: rrjanbiah-at-Y!com
Jul 17 '05 #5

P: n/a
> No, he didn't mean you unset them from the superglobal arrays, he meant
the CORRESPONDING variables (symbols).
ie.
foreach($_REQUEST as $varName => $varVal) unset($varName);


Ahh yeah - I see what you mean now *it all clicks into place*
I'll give it a go when I get back in tonight, see what happens.

Thanks

David
Jul 17 '05 #6

P: n/a
> Is it the problem that I reported once? (
http://bugs.php.net/bug.php?id=22389 )


Yeah, sounds the same - just confirms that i'll probably just have to change
all my variable names! :o(

David
Jul 17 '05 #7

P: n/a
"David Walker" <wb*********@hotmail.com> wrote in message news:<bo**********@wisteria.csv.warwick.ac.uk>...
Is it the problem that I reported once? (
http://bugs.php.net/bug.php?id=22389 )


Yeah, sounds the same - just confirms that i'll probably just have to change
all my variable names! :o(


AFAIK, it is true for 4.3.0. IIRC, it has been fixed in 4.3.2.
So, try to upgrage your PHP.

---
"Learn from yesterday, live for today, hope for tomorrow. The
important thing is to not stop questioning."---Albert Einstein
Email: rrjanbiah-at-Y!com
Jul 17 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.