was wondering if simply including this line at the top of all scripts
would eliminate the potential problem I would have if
register_globals gets turned off unexpectedly?
Other than the security reasons, is there any disadvantage to adding
--- Philip Olson <[EMAIL PROTECTED]> wrote:
> > I have several scripts that take it for granted PHP will assign
> > variables to the information in the URL as in your example $a
> > example.com/foo.php?a=apple
> Okay, so they depend on the behavior that register_globals
> > Will these scripts fail when my commercial Web host upgrades
> > from PHP 4.1.x to 4.2?
> It's not a matter of PHP versions, it's a matter of a
> simple PHP directive. PHP 4.2.0 defaults to
> register_globals = off, this does not mean a host
> has to go by this default. Ask them if it will be
> changing, odds are it will not without a warning.
> > If so, can I 'upgrade' my scripts now (again, PHP 4.1.x) to use
> > $food = $_GET['a'] or $food = $_POST['a'] and prevent everything
> > from crashing when PHP 4.2 is installed?
> Yes you can. I eluded to import_request_variables() and
> extract(), two functions that will allow you to do such
> things. Please look them up in the manual (links below).
> Also consider $_REQUEST, see the manual for details.
> Also note that if you really want register_globals = on
> and the host has it off, you _may_ (depending on the hosts
> configurations) be able to use .htaccess (or equivalent)
> with something like:
> php_flag register_globals on
> Yes there are a lot of options, variety is the spice of life.
> Philip Olson
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php