Sending Variable Problems

aaron_karp

I recently installed PHP and MySQL on my desktop, after about a year of performing all of my site construction and testing on my ISP's remote server.

I've gotten things working pretty well, and followed a simple instruction guide online. However, my scripts don't seem to be able to send variables between each other.

For example, when I post a page back to itself using GET, all of the variables appear in the query string in the address bar, but I can't seem to find any of them from within the page. It doesn't even register my if($Submit) conditionals, which leaves me helpless to post forms back to themselves (or anywhere, for that matter).

The same problem is present with standard <a href=page.php?var=$foo> links as well. The query string looks correct, but the script doesn't think any of the variables have been set.

Please Help - this is really troubling me. Thanks.

-Aaron

OhLordy

register globals is probably set to off (which is a goo thing)
You have to access your valiables through $HTTP_GET_VAR['varname'] or $_GET['varname']

For more info on this do a search through the forums. There should be lots of posts on this.
Good Luck
Rob

paul088

Why can't you use POST instead of GET? Access the submitted variables using $POST[variable_name], for example $POST[submit] instead of $submit.

Good luck.

superwormy

when I post a page back to itself using GET

Um... you CAN'T POST a page using GET method. You can submit a form using GET or you can submit a form using POST, one, or the other.

GET is throught the URL, POST is POST data.

ajmoore

if you want to get the variables sent to the page no matter which method you use(POST or GET) you can access them with $_REQUEST["var"]

Just thought I'd throw that in

BuzzLY

$POST['submit'] will not contain anything unless it is passed from the previous form via a field or hidden input. If you are testing to see if the page is the result of a POST, then test for the existence of one of your fields, like $POST['name']

People that use $POST['submit'] usually have a hidden input like so on their form:

<input type="hidden" name="submit" value="1">

This way, testing for isset($_POST['submit']) will return TRUE.

superwormy

Buzzly, actually most people have this:

In which case print ($_POST['submit']); results in:

Submit My Form!

paul088

superwormy is right. By the way, $_POST[variable] is normally (and necessarily) used in case where submission form and processing script are on the same page. If the form is processed by another page, you can simply use $variable in the processing page for the sake of convenience.

superwormy

paul088 is wrong, $_POST['variable'] is always a neccessary solution UNLESS you have register_globals set to TRUE.

By default, in all new version of PHP register_globals is set to FALSE.

You should be ALWAYS using $POST, $GET, $_REQUEST, etc. for both forward compatibility reasons AND for security reasons!

superwormy

Further, what he said makes no sense, as the recieving page has no clue where it was POSTed from. You should be using $_POST vars in both cases, wether the form POSTs to itself or antoehr form.

paul088

Well, I am not convinced that $_POST[variable] is necessary when the variable is passed to other page. I haven't had any problem with that unless all servers I used have register_globals turned on.

By the way, do I have to have the single quotes around the variable name? It has been working for me without the quotes.

laserlight

Actually, should register_globals be set to On, then paul088's "sake of convenience" argument has some merit, though not enough to warrant not using $_POST

The reason why ppl use $POST['varname'] instead of $POST[varname] is that the PHP manual warns that the key should be a string, so although varname gets treated as a string, it just might not be in future versions, or the string used may conflict with some defined variable.

superwormy, maybe you should be less frank, paul088 did say you were right 😃

paul088

superwormy is absolutely right about register_gloable. I just tested with it on and off. $variable won't work unless it is on. Thanks. I learnt.

superwormy

The VAST majority of web hosts DO have register_globals turned ON. This is because up until just a little while ago register_globals DEFAULTED to ON, and turning it off now would break TONS of their clients scripts.

That doens't change the fact though that its good practice to act as if its turned off.

Also, from teh PHP manual on arrays:

Why is $foo[bar] wrong?
You should always use quotes around an associative array index. For example, use $foo['bar'] and not $foo[bar]. But why is $foo[bar] wrong? You might have seen the following syntax in old scripts:

<?php
$foo[bar] = 'enemy';
echo $foo[bar];
// etc
?>

This is wrong, but it works. Then, why is it wrong? The reason is that this code has an undefined constant (bar) rather than a string ('bar' - notice the quotes), and PHP may in future define constants which, unfortunately for your code, have the same name. It works, because the undefined constant gets converted to a string of the same name automatically for backward compatibility reasons.

http://www.php.net/manual/en/language.types.array.php

Also note I"m not here to convince you of anything... but think about it. Why should POSTing to the same of diff. page make a difference? The recieving page never knows where the POSTed data came from. If you don't believe me, setup a server with register_globals turned off an dtry it yourself.

superwormy

No problem dude, glad I could help!

OhLordy

The biggest danger I am aware of with register_globals is if you use global variables that are not from external sources in your code, in which case I understand there to be some possibility for an attacker to change those values by submitting an extra GET or POST variable.

This may not sound all that bad but suppose you have a variable in your script that holds the path where you are accessing files.
$filepath
and one that holds what action in to be taken
$action

Suppose an attacker changes the address bar to this

http://www.somesite.com/page.php?filepath=/&action=delete

In theory he could delete your / path

This is a rather silly example but it gets accross the idea.
Rob

laserlight

Actually, if you have proper checking of variable datatypes, user permissions etc, that shouldnt be a problem.

Using the predefined arrays just help, they arent security in themselves.

OhLordy

I'd beg to differ. If you have register globals on a user can change the value of any of the variables in your script whether they are designed for user input or not. OK they have to figure out the names of those varibles but that is not allways difficult.

There are a number of security issues around register_globals and the lack of initialization in php. here is a link to a white paper by Shaun Clowes that highlights a number of them.

http://www.securereality.com.au/studyinscarlet.txt

Cheers
Rob

superwormy

I beg to differ with Laserlight, they certaintly are a big help in secuirty :-)

The big problem with regiser_globals on and NOT using $POST or $GET arrays is there's no way to tell where that variable came from. I would consider that alone a security concern, and safer to know where stuff came from.

Theres no way to tell if someone is submitting that data via the URL to play with your app, or to try and break this or whatnot...

Granted, I agree that using $GET and $POST array is not an excuse not to check input / validate datat, thats VERY important indeed, more important for sure. Further since I can't think of a good example to prove laserlight wrong... hehe I guess I'll just insist that it IS important to secuirty... even though I can't prove it at all :-)

superwormy

Thanks for backing me up OhLordy

:-)