SitePoint Sponsor

User Tag List

Results 1 to 18 of 18
  1. #1
    SitePoint Addict mserms's Avatar
    Join Date
    Jun 2001
    Location
    Scotland
    Posts
    230
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Parameter Passing in PHP - AARRRGGHHHH!

    I've setup Apache, PHP4 and MySQL on my linux Mandrake 8.0 machine. They all appear to work well together EXCEPTING the fact that I am not able to pass variable information between PHP pages. Here are a couple of pages that I am using to test this. I've already tried POST instead of GET for the method.

    Can anyone help? This is driving me nuts! Could it be the way I've set up Apache or PHP?

    Thanks a lot,

    Mark



    start.php:
    <HTML>
    <BODY>
    <FORM ACTION="final.php" METHOD=GET>
    First Name: <INPUT TYPE=TEXT NAME="firstname"><BR>
    Last Name: <INPUT TYPE=TEXT NAME="lastname">
    <INPUT TYPE=SUBMIT VALUE="GO">
    </FORM>
    </BODY>
    </HTML>


    final.php:
    <HTML>
    <BODY>
    <p>Welcome,
    <?php
    echo "".$firstname." ";
    echo $lastname;
    ?>
    </p>
    </BODY>
    </HTML>

  2. #2
    You talkin to me? Anarchos's Avatar
    Join Date
    Oct 2000
    Location
    Austin, TX
    Posts
    1,438
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    In your php.ini register_globals needs to be on.

  3. #3
    SitePoint Wizard johnn's Avatar
    Join Date
    Mar 2001
    Location
    Southern California, USA
    Posts
    1,181
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,
    It look ok to me. How about change start.php to start.html

    John

  4. #4
    ********* Callithumpian silver trophy freakysid's Avatar
    Join Date
    Jun 2000
    Location
    Sydney, Australia
    Posts
    3,798
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As Anarchos explains, you need to check whether register_golabals is on in your php.ini file. There are two different default php.ini files included with the install. The optimised version has register_globals turned off and the other has them turned on.
    I mentioned these two files yesterday here : http://sitepointforums.com/showthrea...threadid=26011

    When I was reading the README file I found it odd that it said that the php developers viewed register_globals as depricated and that programmers should instead use the relevent arrays $HTTP_GET_VARS and _$HTTP_POST_VARS to access data passed to the page. Does anyone know why this is so? Is it purely for efficiency and not taking up extra memory (and if that is the only reason it doesn't seem very relevent because of the way the Zend optimiser handles having multiple variables which hold the same values as pointers to the value)? I am affraid that I continue to make use of the register_globals feature by default in my code and notice that most of the posters here do. So we are writing depricated code!

    In any case, even if register_globals is turned off in php.ini you can always explode the array yourself to create variables from the associative array elements:

    explode($HTTP_POST_VARS);
    explode($HTTP_GET_VARS);

  5. #5
    You talkin to me? Anarchos's Avatar
    Join Date
    Oct 2000
    Location
    Austin, TX
    Posts
    1,438
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Didn't know it was deprecated

    The reason is security, using register_globals is very insecure (although very convenient). Because it's so convenient, most scripts require it to be to turned on, so it's a pain to switch your site from on to off.

  6. #6
    ********* Callithumpian silver trophy freakysid's Avatar
    Join Date
    Jun 2000
    Location
    Sydney, Australia
    Posts
    3,798
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Can you provide any further info on the security issue. I am very interested to know more.

  7. #7
    You talkin to me? Anarchos's Avatar
    Join Date
    Oct 2000
    Location
    Austin, TX
    Posts
    1,438
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I haven't read anything about it, because it's not especially complicated: it just allows users to spoof and/or manipulate form and cookie data. If you design well this won't be much of a problem, but you still can't trust any form or cookie data to be legitimate. For example, you might have a script that looks like this:

    if ($username && $password){
    //you're logged in
    //display user account info
    select * from users where username='$username'
    //etc.
    }
    else {
    //display login form
    }

    You have a login script that checks $loginuser and $loginpass and if they're in the db you set cookies for $username and $password and they're logged in. But someone could go up and do display.php?username=admin&password=blah
    and your website is hosed.

    Or say you've got some sort of page to edit a row, but you only allow the person to access certain rows:
    <input type="hidden" name="id" value="10">
    Change your password: <input type="text" name="newpassword">
    ...input data for the row here...

    and at the top you have:
    if ($id){
    if ($newpassword)
    mysql_query("update users set password='$newpasword' where id=$id");
    }

    They can modify whatever row they want by doing blah.php?id=x&newpassword="hackedaccount"...

    Basically, setting register_globals to off will greatly decrease the possibility of receiving tainted or modified data. You can always do lots of checks to make sure your data is valid, but turn off register globals will help with anything you miss or don't think of protecting (Murphy's Law).

  8. #8
    You talkin to me? Anarchos's Avatar
    Join Date
    Oct 2000
    Location
    Austin, TX
    Posts
    1,438
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Also, I should note that I'm very lazy and don't keep my scripts especially secure. For my links and admin scripts for example, I don't have any password protection or anything, I just count on my users not guessing the urls .Of course this is just for my personal site so I don't have any particularly important data, just news, links, and guestbook.

  9. #9
    ********* Callithumpian silver trophy freakysid's Avatar
    Join Date
    Jun 2000
    Location
    Sydney, Australia
    Posts
    3,798
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for the reply. Yes I understand the issue from that perspective. I am currently writing some scripts which involve a member sign up process that spans several forms on several pages. So at the beginning of each script I am checking that the $HTTP_POST_VARS contains the keys I am expecting and requiring it to be receiving from the preceding form AND additionally checking that the referer is indead the page containing that form. I also don't want people spoofing the form data.

    Yes, I can now see that having register_globals off will add to the security if I foul up and miss writing the checks into my code. Hmm, good point!

  10. #10
    SitePoint Author Kevin Yank's Avatar
    Join Date
    Apr 2000
    Location
    Melbourne, Australia
    Posts
    2,571
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    I keep register_globals on in all my code. Generally it's pretty safe as long as you always keep in mind all the sources that a variable can come from.

    For example, if you want to make sure that a flag variable $isLoggedIn is coming from a stored session variable, and not just some clever hacker who tacked ?isLoggedIn=1 to the end of a URL, you should unset the variable at the top of your script:

    PHP Code:
    // For security
    unset($isLoggedIn);

    session_start();

    if (
    $isLoggedIn) ... 
    File uploads are another instance where it's important to know where your data is coming from. It's all too easy to trust that $uploaded_file contains the filename uploaded from a form, when in fact someone may have just loaded ?uploaded_file=/etc/passwd and your unsuspecting script is about to email it to the user! That's where PHP's is_uploaded_file function comes in handy.
    Last edited by Kevin Yank; Jun 18, 2001 at 05:57.
    Kevin Yank
    CTO, sitepoint.com
    I wrote: Simply JavaScript | BYO PHP/MySQL | Tech Times | Editize
    Baby’s got back—a hard back, that is: The Ultimate CSS Reference

  11. #11
    SitePoint Member
    Join Date
    Jun 2001
    Location
    usa
    Posts
    13
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Its also just generally a frowned upon practice these days to have infinite possible variables of global scope. Most everything is supposed to have specific structured scope within a class or function. If you want to share information, you always do so by parameters, which passes the value(or the location of the value)...not the variable itself. This is basically just "good programming practice"

  12. #12
    SitePoint Addict mserms's Avatar
    Join Date
    Jun 2001
    Location
    Scotland
    Posts
    230
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Being a bit of a grommit, I'm not sure where to locate my php.ini. A search reveals only one such file, stored in /etc I checked this file but the register_globals is et ON. Are there any other copies of php.ini floating around that I need to change? (I installed to /usr/local/php if that matters). Apache also will not run from startup. I need to go to /usr/local/apache/bin and type ./httpd - I *THINK* that apache USED to runon startup, but I'm not sure. Has this got anything to do with the problem?

    Thanks again,

    Mark

  13. #13
    SitePoint Author Kevin Yank's Avatar
    Join Date
    Apr 2000
    Location
    Melbourne, Australia
    Posts
    2,571
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    The location of php.ini depends on how you installed PHP. If you're using the version that comes with Mandrake 8.0, then /etc/php.ini is where it belongs...
    Kevin Yank
    CTO, sitepoint.com
    I wrote: Simply JavaScript | BYO PHP/MySQL | Tech Times | Editize
    Baby’s got back—a hard back, that is: The Ultimate CSS Reference

  14. #14
    SitePoint Addict mserms's Avatar
    Join Date
    Jun 2001
    Location
    Scotland
    Posts
    230
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I first installed PHP with Mandrake 8 but had to uninstall it because of problems with mysql...etc.. I'm not sure if the RPM uninstaller kills all of the files or not. It could just be an old one that is lying around. I re-installed with the tar version to usr/local/php. Hmmm. This one is really puzzling me. I think it's related to apache but I'm far from sure.

    Any ideas?

    Mark

  15. #15
    SitePoint Author Kevin Yank's Avatar
    Join Date
    Apr 2000
    Location
    Melbourne, Australia
    Posts
    2,571
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    If you installed from source, you must copy the php.ini-dist file from the PHP distribution to the /usr/local/php directory. The installation doesn't do this for you.
    Kevin Yank
    CTO, sitepoint.com
    I wrote: Simply JavaScript | BYO PHP/MySQL | Tech Times | Editize
    Baby’s got back—a hard back, that is: The Ultimate CSS Reference

  16. #16
    SitePoint Addict mserms's Avatar
    Join Date
    Jun 2001
    Location
    Scotland
    Posts
    230
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I managed to get it sorted about an hour before I hitch-hiked for 3 days in an attempt to go rock-climbing (but only to get very wet as it turned out). I finally found several copies of php.ini (thanks to various installations) and as kyank says the file that gets used is the one in /usr/local/php. I need to learn about the locate command as I was under the impression that it searches all files. After this little lesson, it would appear not.

    Anyway, take it easy and thanks for all the help.

    Mark

  17. #17
    SitePoint Author Kevin Yank's Avatar
    Join Date
    Apr 2000
    Location
    Melbourne, Australia
    Posts
    2,571
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Try 'man locate'. It'll tell you how to update the locate database with recently added files.
    Kevin Yank
    CTO, sitepoint.com
    I wrote: Simply JavaScript | BYO PHP/MySQL | Tech Times | Editize
    Baby’s got back—a hard back, that is: The Ultimate CSS Reference

  18. #18
    SitePoint Addict mserms's Avatar
    Join Date
    Jun 2001
    Location
    Scotland
    Posts
    230
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The man pages are useful.

    Thanks


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •