Die Variablen - vom Update auf PHP 4.2

Wer das hier liest hat ein Problem, ein großes Problem - seine Scripte laufen nicht mehr. Und man hat in der Regel nicht einmal etwas geändert. Aber jetzt erstmal: Nur die Ruhe, keine Panik kriegen, das bekommen wir schon wieder hin.
Wen betrifft dieser Text überhaupt?
Nun, der typische Anwender mit den beschriebenen Problemen zeigt folgende Merkmale:

a) sein Provider oder er selbst haben ein aktuelles PHP in Version 4.2 oder höher laufen. Möglicherweise auch niedrigere Versionen, aber das ist eher untypisch.

b) wenn er eine Datei wie die folgende ausführt
phpinfo();
?>
entdeckt er eine Zeile die ihm sagt, dass "register_globals" auf "Off" geschaltet ist.

c) er verwendet Variablen, die "in der URL" (per GET-Request) übergeben werden und diese sind "auf einmal nicht mehr da". Analog natürlich auch für POST-Requests, Cookies etc.

Auf wen das obige nicht zutrifft, der braucht diesen Artikel nicht mehr weiter zu lesen und darf wieder Panik bekommen. Der gesamte Rest findet hier Erleuchtung.

Was ist passiert?

Nun, diese Frage stellt sich den meisten zwar nicht zuerst, aber wie will man ein Problem lösen, dessen Ursache man nicht kennt? Also:
In PHP gibt es eine Einstellung, die in der zentralen Konfigurationsdatei - der php.ini - getätigt werden kann und sich register_globals nennt. Diese ist dafür zuständig, dass Variablen direkt unter ihrem namen verfügbar sind, also bei einem Aufruf von "index.php?seite=test" eine Variable $seite existiert und "test" enthält. Diese ist eigentlich ganz praktisch, aber auch eine gefährliche Falle wie wir später sehen werden.
Jedenfalls haben sich die Entwickler von PHP entschlossen, diese Einstellung ab PHP 4.2 auszuschalten. Die Variablen werden also in der Standardkonfiguration nicht mehr so wie früher zur Verfügung gestellt.

Wieso haben die das gemacht?

Die Überlegungen hinter dieser Entscheidung sind für uns normale Anwender auf den ersten Blick ziemlich mysteriös: Wieso sollte jemand so etwas praktisches Ausschalten?
Folgendes Beispiel:
Viele Seiten verwenden geschützte Bereiche irgendwelcher Art, zum Beispiel zur Administration. In vielen Scripten findet sich hierzu eine Weiterleitung auf eine Seite oder andere Methode eine Seite zu laden, die ein Passwort abfragt, wenn sich in der Session keine Variable wie etwa $validuser = 1; befindet. Wenn diese Variable gesetzt ist kann angenommen werden, dass der Benutzer bereits authentifiziert ist.
Jetzt kommt der Haken hieran:
Ein Aufruf der fiktiven /administration/index.php Seite mit "index.php?validuser=1" macht was? Genau, es lässt jeden Benutzer ohne nötige Authentifizierung an die Administratierung der Seite.

Das Beispiel mag an den Haaren herbeigezogen wirken, aber in der Tat findet man häufig Scripte die solche Sicherheitslücken haben, auch wenn sie dort nicht so tragisch wirken. Die Entwickler hatten also allen Grund dieses Verhalten von PHP standardmäßig einzuschränken, um die ausgeführten Scripte sicherer zu machen.

GET? POST? Was ist das?

Wer sich die obigen Fragen beantworten kann, kann diesen Abschnitt getrost überspringen, aber hier wird später benötigtes Basiswissen vermittelt.
Es handelt sich hinter diesen kurzen Wörtchen wie "GET-Request" oder "POST-Request" darum, wie Werte an den Webserver übertragen werden. Dabei handelt es sich um zwei ziemlich verschiedene Vorgehensweisen:
Bei einem GET-Request werden die Daten innerhalb der Anfrage der Seite an den Server aufgenommen - man sieht die Variablen also in der Adresszeile des Browsers.
Ein POST-Request geht jedoch anders vor und überträgt die Daten zwar auch beim Aufruf der Seite an den Server, aber außerhalb der Adresse der Seite in speziell dafür vorgesehenen Teilen der Anfrage - der Benutzer sieht die Daten also nicht in der Adresszeile.
Es ist, um das Problem lösen zu können, wichtig zu wissen, wie die Daten an den Server übertragen werden. Generell kann man dies aber auch an seinem eigenen HTML-Quelltext erkennen:
Wenn man ein Formular verwendet findet sich im