[:de]

Drei Tage lang wäre ich fast verzweifelt, als ich eine WordPress-Seite um ein selbstgeschriebenes Login-Script erweitern wollte. Lokal funktionierte alles einwandfrei, doch sobald ich es hochgeladen hatte, schienen die Session-Variablen nicht mehr übernommen zu werden: nach dem Login war man jeweils einen Klick lang eingeloggt und danach sofort wieder ausgeloggt.

[:] [:en]

For three days I had nearly despaired when I tried to extend a WordPress site with a self-written login script. Everything worked properly on my local server, but as soon as I had uploaded it, the session variables didn’t seem to be passed any more: after the login, I stayed logged in for only one more click and then got logged out again.

[:] [:de]

Nach etlichen erfolglosen Google-Suchen (im Nachhinein googelt es sich ganz leicht danach, aber versucht mal was dazu zu finden, nachdem Ihr nicht weiter als bis hierher gelesen habt) fand ich endlich die Ursache, nämlich die Funktion wp_unregister_GLOBALS() in der Datei wp-settings.php. Hier ist sie:

function wp_unregister_GLOBALS() {
    if ( !ini_get('register_globals') )
        return;

    if ( isset($_REQUEST['GLOBALS']) )
        die('GLOBALS overwrite attempt detected');

    // Variables that shouldn't be unset
    $noUnset = array('GLOBALS', '_GET', '_POST', '_COOKIE', '_REQUEST', '_SERVER', '_ENV', '_FILES', 'table_prefix');

    $input = array_merge($_GET, $_POST, $_COOKIE, $_SERVER, $_ENV, $_FILES, isset($_SESSION) && is_array($_SESSION) ? $_SESSION : array());
        foreach ( $input as $k => $v )
            if ( !in_array($k, $noUnset) && isset($GLOBALS[$k]) ) {
                $GLOBALS[$k] = NULL;
                unset($GLOBALS[$k]);
            }
}

Was macht diese Funktion?

• Zeile 27/28:
  Wenn auf dem Webserver die PHP-Einstellung register_globals nicht aktiviert ist, dann macht sie überhaupt nichts (daher auch die unterschiedlichen Verhaltensweisen meines Scripts auf meinem lokalen und dem Live-Server). Ist register_globals jedoch aktiv, geht es folgendermaßen weiter:
  • Zeile 34:
    Wie der Kommentar schon sagt, werden hier alle globalen Variablen aufgelistet, die nicht resettet werden sollen. Wie man sieht, ist $_SESSION nicht dabei!
  • Zeile 36-41:
    Nun werden nacheinander alle globalen Variablen durchgegangen und gelöscht.

Kurz gesagt: Wenn register_globals aktiviert ist, wird $_SESSION bei jedem Seitenaufruf gelöscht. Kein Wunder also, daß man nicht mehr an seine Session-Variablen rankommt!

Wozu das Ganze?

Nun ja, zum einen geht WordPress davon aus, daß es sich komplett um jeden Bereich der Seite kümmern soll – schließlich ist es ja eine Art von Content-Management-System. Und das beinhaltet eben auch, daß es die Verwaltung sämtlicher Variablen übernimmt.

Was aber noch viel wichtiger ist, ist die Tatsache, daß die Verwendung von register_globals längst veraltet ist und das Feature mit PHP 6 sogar komplett entfernt wird. Von der Programmierung mit solchen Variablen wird inzwischen überall abgeraten, da sie Sicherheitsrisiken birgt. WordPress versucht also offensichtlich, das Verhalten von deaktiviertem register_globals nachzuahmen, um die Sicherheit zu erhöhen und eventuelle Variablenkonflikte zu vermeiden.

Abhilfe

Nachdem ich erst einmal hinter dieses Rätsel gekommen war, lag die Lösung natürlich auf der Hand: Ich muß register_globals auf dem Webserver deaktivieren, damit WordPress diese bescheuerte Funktion gar nicht erst auszuführen braucht. Dazu lädt man einfach in sein WordPress-Verzeichnis eine Textdatei namens php.ini hoch, in der die folgende Zeile steht:

register_globals Off

Weitere Informationen zum Thema gibt es auf php.net:

• Welche Bedeutung hat die PHP-Direktive register_globals für mich?
• Verwendung von Register Globals
• Superglobals

[:] [:en]

After several unsuccessful Google searches (with the wisdom of hindsight it’s quite easy to google, but try and find something about this issue without reading any further than this) I found the reason at last, namely the function wp_unregister_GLOBALS() inside the file wp-settings.php. Here it is:

function wp_unregister_GLOBALS() {
    if ( !ini_get('register_globals') )
        return;

    if ( isset($_REQUEST['GLOBALS']) )
        die('GLOBALS overwrite attempt detected');

    // Variables that shouldn't be unset
    $noUnset = array('GLOBALS', '_GET', '_POST', '_COOKIE', '_REQUEST', '_SERVER', '_ENV', '_FILES', 'table_prefix');

    $input = array_merge($_GET, $_POST, $_COOKIE, $_SERVER, $_ENV, $_FILES, isset($_SESSION) && is_array($_SESSION) ? $_SESSION : array());
        foreach ( $input as $k => $v )
            if ( !in_array($k, $noUnset) && isset($GLOBALS[$k]) ) {
                $GLOBALS[$k] = NULL;
                unset($GLOBALS[$k]);
            }
}

What does this function do?

• Line 27/28:
  If register_globals is not activated in the PHP settings of the web server, it won’t do anything at all (which explains the different behaviours of my script on my local and the live server). If, however, register_globals is active, it proceeds as follows:
  • Line 34:
    As the comment already says, all global variables listed here will not be reset. As you can see, $_SESSION is not being mentioned!
  • Line 36-41:
    Now, all global variables are being shifted and deleted one by one.

In short: If register_globals is activated, $_SESSION will be deleted on every single page view. No surprise that we can’t get at our session variables any more!

What’s it all about?

Well, for one thing, WordPress assumes that it’s meant to take care of the complete site – after all it is some kind of content management system. And that includes the administration of all variables as well.

What’s much more important though, is the fact, that the use of register_globals has been deprecated for a long time and the feature will even be completely removed in PHP 6. Today, it is strongly recommended not to use these kind of variables, because they involve safety hazards. So, WordPress is obviously trying to imitate the behaviour of a deactivated register_globals in order to ensure safety and avoid potential variable conflicts.

Remedy

After having solved this riddle, the solution was perfectly obvious: I have to deactivate register_globals on the web server, so WordPress wouldn’t even need to execute that stupid function. For this purpose, simply place a text file called php.ini inside your WordPress directory, containing the following line:

register_globals Off

Further information on the subject can be found on php.net:

• How does the PHP directive register_globals affect me?
• Using Register Globals
• Superglobals

[:]