Should I design for servers with register_globals switched off?

[ChronicFatigue]

Hello

My current host has register_global s switched on in their php.ini file.

Would it be prudent for me to design code which works when register_global s
is switched off in case I switch hosts in the future? If I dont is it
normally straightforward to edit the code so that a script can be run with
register_global s off in the future?

Just trying to future proof my work abit.

Simon

[ChronicFatigue]

Re: Should I design for servers with register_global s switched off?

Thanks for the response...

Are there are other 'fundamental tips' you may have regarding how you should
code now to avoid potential difficulties when changing servers in the
future?





"stephan beal" <stephan@wander inghorse.net> wrote in message
news:bflv7b$75q $2@ork.noris.ne t...[color=blue]
> ChronicFatigue wrote:[color=green]
> > Would it be prudent for me to design code which works when
> > register_global s is switched off in case I switch hosts in the future?[/color][/color]
If[color=blue]
>
> YES, and not only for that reason. Try maintaining someone's code which is
> scattered across 10 php files and uses global variables. It's damned near
> impossible. Avoid globals at all costs.
>
> --
> ----- stephan beal
> Registered Linux User #71917 http://counter.li.org
> I speak for myself, not my employer. Contents may
> be hot. Slippery when wet. Reading disclaimers makes
> you go blind. Writing them is worse. You have been Warned.
>[/color]

[stephan beal]

Re: Should I design for servers with register_global s switched off?

ChronicFatigue wrote:
[color=blue]
> Thanks for the response...
>
> Are there are other 'fundamental tips' you may have regarding how you
> should code now to avoid potential difficulties when changing servers in
> the future?[/color]

a) avoid the use of paths in your code. e.g., include(
"dir/anotherdir/something.inc.p hp" );

b) instead of using include() and require(), write classloader-like
replacements for them and use those to find your files for you. This is not
as hard as it sounds: 1 hour of work or so. Contact me off-list if you'd
like some sample code.
old style:
include( 'path/to/foo.inc.php' );
more generic approach:
my_include( 'foo' );

c) if you make heavy use of classes, write a classloader (they're EASY to
implement in PHP). Again, contact me off-list if you'd like some sample
code for this.
old style:
include( '/path/to/Foo.class.php' );
$foo = new Foo();
with classloader:
$foo =& classload( 'Foo' );
if( ! $foo ) { /* it didn't find the class */ }

d) avoid global vars at all costs. For example, i use the following function
to get at global vars:
############### ############### ############### ############### ############### #####
# r_find_var():
# i was sick of trying to figure out if a var was in GLOBALS or one of
# HTTP_xxx_VARS, so i wrote this laziness fixer.
# Looks in GLOBALS, HTTP_(POST,GET, SERVER,COOKIE)_ VARS (in that order)
# for the given var, or returns a reference to $defaultval.
function & r_find_var( $var, $defaultval = null ) {
global $HTTP_COOKIE_VA RS, $_r_flags;
foreach( array(
$GLOBALS,
$_GET,
$_POST,
$_SERVER,
$_COOKIES
)
as $ar ) {
if( isset( $ar[$var] ) ) return $ar[$var];
}
return $defaultval;
}


Then all of your global lookups look like:

$foo =& r_find_var( 'field_from_for m', 42 );
if( $foo == 42 ) { /* it wasn't set */ }

This saves you from the primacy of things like:

$foo = $_POST['foo'];
if( ! $foo ) { $foo = $_GET['foo']; }
if( ! $foo ) { $foo = $GLOBALS['foo']; }
// ad nauseum...

i really think those are the most important bits. i cannot over-state the
maintenance benefits of using a classloader and classloader-like
replacements for include() and require(). They make your code much more
mobile and much easier to maintain. With those you can move your included
files whereever you like, update one config file (which is part of your
app, not part of the PHP setup) and you don't have to change any other
code.

:)

About the sample code: you can find it buried in the source tarball
available here if you like:

http://stephan.rootonfire.org/radioaqtiph/

the more generic bits are in classes/core/*.class.php
but some of those classes aren't useful and may be downright bogus
(TypedList.clas s.php comes to mind).

There you can also find an example of a classloader which CREATES classes on
the fly from a mysql database.

--
----- stephan beal
Registered Linux User #71917 http://counter.li.org
I speak for myself, not my employer. Contents may
be hot. Slippery when wet. Reading disclaimers makes
you go blind. Writing them is worse. You have been Warned.

[ChronicFatigue]

Re: Should I design for servers with register_global s switched off?

Excellent post Stephan thanks for this.

Will look into these points you mention and thanks for the offer of sample
code.




"stephan beal" <stephan@wander inghorse.net> wrote in message
news:bfmcmn$dfr $1@ork.noris.ne t...[color=blue]
> ChronicFatigue wrote:
>[color=green]
> > Thanks for the response...
> >
> > Are there are other 'fundamental tips' you may have regarding how you
> > should code now to avoid potential difficulties when changing servers in
> > the future?[/color]
>
> a) avoid the use of paths in your code. e.g., include(
> "dir/anotherdir/something.inc.p hp" );
>
> b) instead of using include() and require(), write classloader-like
> replacements for them and use those to find your files for you. This is[/color]
not[color=blue]
> as hard as it sounds: 1 hour of work or so. Contact me off-list if you'd
> like some sample code.
> old style:
> include( 'path/to/foo.inc.php' );
> more generic approach:
> my_include( 'foo' );
>
> c) if you make heavy use of classes, write a classloader (they're EASY to
> implement in PHP). Again, contact me off-list if you'd like some sample
> code for this.
> old style:
> include( '/path/to/Foo.class.php' );
> $foo = new Foo();
> with classloader:
> $foo =& classload( 'Foo' );
> if( ! $foo ) { /* it didn't find the class */ }
>
> d) avoid global vars at all costs. For example, i use the following[/color]
function[color=blue]
> to get at global vars:
>[/color]
############### ############### ############### ############### ############### #
####[color=blue]
> # r_find_var():
> # i was sick of trying to figure out if a var was in GLOBALS or one of
> # HTTP_xxx_VARS, so i wrote this laziness fixer.
> # Looks in GLOBALS, HTTP_(POST,GET, SERVER,COOKIE)_ VARS (in that order)
> # for the given var, or returns a reference to $defaultval.
> function & r_find_var( $var, $defaultval = null ) {
> global $HTTP_COOKIE_VA RS, $_r_flags;
> foreach( array(
> $GLOBALS,
> $_GET,
> $_POST,
> $_SERVER,
> $_COOKIES
> )
> as $ar ) {
> if( isset( $ar[$var] ) ) return $ar[$var];
> }
> return $defaultval;
> }
>
>
> Then all of your global lookups look like:
>
> $foo =& r_find_var( 'field_from_for m', 42 );
> if( $foo == 42 ) { /* it wasn't set */ }
>
> This saves you from the primacy of things like:
>
> $foo = $_POST['foo'];
> if( ! $foo ) { $foo = $_GET['foo']; }
> if( ! $foo ) { $foo = $GLOBALS['foo']; }
> // ad nauseum...
>
> i really think those are the most important bits. i cannot over-state the
> maintenance benefits of using a classloader and classloader-like
> replacements for include() and require(). They make your code much more
> mobile and much easier to maintain. With those you can move your included
> files whereever you like, update one config file (which is part of your
> app, not part of the PHP setup) and you don't have to change any other
> code.
>
> :)
>
> About the sample code: you can find it buried in the source tarball
> available here if you like:
> http://stephan.rootonfire.org/radioaqtiph/
> the more generic bits are in classes/core/*.class.php
> but some of those classes aren't useful and may be downright bogus
> (TypedList.clas s.php comes to mind).
>
> There you can also find an example of a classloader which CREATES classes[/color]
on[color=blue]
> the fly from a mysql database.
>
> --
> ----- stephan beal
> Registered Linux User #71917 http://counter.li.org
> I speak for myself, not my employer. Contents may
> be hot. Slippery when wet. Reading disclaimers makes
> you go blind. Writing them is worse. You have been Warned.
>[/color]

[Marcus]

Re: Should I design for servers with register_global s switched off?

ChronicFatigue wrote:[color=blue]
>
> My current host has register_global s switched on in their php.ini file.
>[/color]

Simon,

I'm guessing you don't have access to the php.ini file, but you can
probably turn register_global s off using phpflag... I'm sure you
probably already know, but it's better if you can code with it off
instead of on.

Marcus

[stephan beal]

Re: Should I design for servers with register_global s switched off?

sam wrote:
[color=blue]
> Me too: Excellent post Stephan thanks for this.[/color]

Thanks :)
[color=blue]
> I think there is a scurity problem with your function r_find_var
> (if you haven't an other function or like to check for variable
> injection): One can easily inject variables into the $_GET array to
> override $_SERVER variables. For example:[/color]

Oh, absolutely. i'm the last person in the world to feel concerned about
security, though ;). Seriously, though, for the type of coding i do it is
completely insignificant whether someone forges a form, because all data
authentication still requires a valid user. For example, i've implemented a
unix-like access rights system that gets applied to all of my database
tables, and any forms which end up updating db fields must then pass that
security.


--
----- stephan beal
Registered Linux User #71917 http://counter.li.org
I speak for myself, not my employer. Contents may
be hot. Slippery when wet. Reading disclaimers makes
you go blind. Writing them is worse. You have been Warned.