View Full Version : php HTTP_POST_VARS don't work
01-04-2003, 10:14 AM
I'm running standard Apple Apache (OSX 10.2.3 / apache 1.3.27) with PHP 4.2.3 installed as per Mark Liyanage's excellent installers etc. (www.entropy.ch), and
Everything is fine except I cannot use a URL such as
The page loads fine, but $func is empty.
Load the same page(s) on to other web servers with appropriate PHP installations etc. and it all works fine.
I saw some stuff about this being a known issue with OSX server a while back, but can't find anyone who's reported this for "ordinary" OSX consumers. The "fix" suggested there doesn't appear to be relevant to Jaguar anyway...
I did the whole install again on a 2nd machine and get exactly the same results.
All the httpd.conf settings appear to be present and correct and the permissions look fine to me...
Anyone got any ideas on this - it's dull having to upload to another (Linux!) server to test!
looks like you stepped into the trap :)
in php4, the "gobals" were disabled. either, enable them or use this:
$func = $HTTP_POST_VARS['func'];
before using the variable.
01-04-2003, 12:52 PM
Unless I'm missing something so fundamental that I should just shut up and RTFM (more), the use of the explicit $HTTP_POST_VARS syntax to grab this isn't the answer. I tried this and it doesn't work either.
The linux server(s) that work are running PHP4 in various versions. They work with or without the $HTTP_POST_VARS syntax.
The OSX Mac does not. I think there's something about the Apache config, or maybe the PHP build supplied by Mark Liyanage, that doesn't handle this.
Mark's posted that he's away until the end of the month and would appreciate a managable mailbox on his return, so I figured that as his implementation is widely promoted (including here) and highly regarded, someone else might have come across this too...
Am I being really dumb or is there an issue here?
01-04-2003, 03:43 PM
The "problem" is in PHP 4.2.3. Register Globals is set to off by default. That means that post vars like index.php?id=1 will not be made a global variable. To use the above variable do this in your code:
$id = $_GET['id'];
Or if its a post var, do this:
$id = $_POST['id'];
This makes much more secure code, you know where your vars come from, and your scripts are less easy to hack.
On the other hand, if you dont write your own scripts Register Globals might be nice. In that case just make a line in your php.ini file that says:
registerglobals = on
If you havent used php.ini before its probably not there, but you can just create it. It is supposed to be in: /usr/local/lib/
If the directories are not there, just create them. Then do a pico /usr/local/lib/php.ini and insert registerglobals = on and restart apache like this: sudo apachectl graceful
And youre set to go :)
01-04-2003, 03:52 PM
OK, I finally figured this out... (with help from seb2's response of course!)
The answer is that it's PHP 4.2.0 and subsequent releases that set the register_globals default to "off", whereas previously it was "on". I'm using 4.2.3 and hence it doesn't work. The other servers were all PHP4, but pre 4.2. QED.
[As an aside, note that phpMyAdmin is damning about 4.2.3 and advises against its use - I'll take this up with Mark Liyanage when he's back in circulation, though I'm sure if there is a real issue here he'll be on to it like a shot anyway.]
Now... how to use this syntax with >= PHP 4.2?
The php manual states that the decision to set this flag "off" was taken to improve security. This makes sense, as inserting guessed variable values into URLs could cause havoc in some instances. So rather than simple setting the flag "on", which recreates the entry route for the hackers we use something like this:
with corresponding php in test.php along the lines of:
$myData = $_GET['param1'];
and voila, it all works as it used to with $myData = "hello".
My apologies if this is teaching many of you to suck eggs, but I thought I'd write in out in simple terms for other total newbies like me who run into the same problem.
vBulletin® v3.8.7, Copyright ©2000-2013, vBulletin Solutions, Inc.