Archive for January, 2009

Doner Kebabs are bad for you

Tuesday, January 27th, 2009

Officials from councils sampled nearly 500 Doner kebabs and found that they may contain up to 4.2MJ of energy and “shocking” levels of salt and saturated fat. Link to BBC story

No s#!t, Sherlock.

Another register_globals cock-up

Tuesday, January 13th, 2009

When I first started programming in PHP, register_globals was on by default. That was just the way things were; if you had a form field called user, you would get a variable $user appearing magically in your script. And everyone was happy.

Including crackers and script kiddies, who were able to override internal variables with crafted requests and so cause badly-written scripts to behave in ways the writers never thought of. If you didn’t initialise variables properly (And I blame Microsoft for that. Their dialect of BASIC silently initialised numeric variables to zero and strings to “” if you tried to read them before you assigned anything to them. The Sinclair and BBC dialects of BASIC would protest with a “no such variable” error if you tried to read a value from a variable that hadn’t been assigned [and Sinclair BASIC added the LET verb, because a program line had to start with a verb -- that was a constraint of the editor]. The only exception is something like Y = Y + 1, which does work. The reason for that is that the interpreter sees Y = and so reserves some space for a brand new variable Y. Then it tries to evaluate the expression Y + 1 and now there is a variable called Y), or if you relied on a variable coming from $_SESSION not being clobbered by a GET or POST request, well, you got what you deserved.

So in PHP version 4.something, they changed the default behaviour so register_globals was off by default. Now you had to look in $_REQUEST for your form data, or even $_POST, $_GET or $_COOKIE if you cared exactly where it came from. Of course, this broke everyone’s scripts; but if you couldn’t simply re-enable register_globals, then a few lines at the beginning of your script restored the old-style behaviour.

You’d think, therefore, that if you kept register_globals off in your development environment (my desktop running Debian Sid) then yourt scripts ought to run fine on a server with register_globals on (as the deployment environment happened to be). But you’d be wrong. If you take a script which works perfectly with register_globals off and try to run it on a server with register_globals on, and you are using session variables, weirdness ensues.

With register_globals off you can have a variable $foo in your program and a session variable $_SESSION["foo"] and they are absolutely, completely, utterly independent of one another. Once register_globals is turned on, however, it’s a different story. Having assigned $_SESSION["foo"] in one script, any attempt in a subsequent script to assign anything to $foo will also assign $_SESSION["foo"] — even if you haven’t used session_resister() to mark $foo explicitly as a session variable.

I have since formulated a new rule-of-thumb:
Any attempt to combine two “intuitive” behaviours will result in a “counter-intuitive” behaviour.