Namespaces und Autoloading (PSR-4)

Kurz gesagt: Namespaces sind in PHP so etwas wie Ordner für Klassennamen: App\Rechnung\Pdf und Bibliothek\Pdf können nebeneinander existieren, ohne sich zu stören. Autoloading sorgt dafür, dass PHP eine Klasse erst dann lädt, wenn sie zum ersten Mal gebraucht wird. Der Standard PSR-4 legt fest, wie aus einem Klassennamen ein Dateipfad wird; Composer erzeugt danach den passenden Autoloader. Weil dieser Autoloader bei jeder Anfrage läuft, gehört er nach einem Sicherheitsvorfall zu den ersten Dingen, die geprüft werden.

Warum PHP Namespaces braucht

Namespaces gibt es seit PHP 5.3.0. Vorher teilten sich alle Klassen und Funktionen einen einzigen globalen Namensraum. Hießen zwei Bibliotheken Logger, krachte es. Entwickler halfen sich mit langen Namen wie Firma_Modul_Unterbereich_Logger.

Das PHP-Handbuch nennt zwei Probleme, die Namespaces lösen: Namenskollisionen zwischen eigenem Code, PHP-internen Klassen und Bibliotheken von Drittanbietern, sowie überlange Namen, die nur zur Umgehung dieser Kollisionen entstanden sind. Für Entscheider bedeutet das: Erst Namespaces haben es praktikabel gemacht, Dutzende fremde Pakete in einem Projekt zu kombinieren, wie es mit Composer heute üblich ist.

Namespaces in der Praxis: namespace, use, Aliase

Eine Datei deklariert ihren Namespace in der ersten Anweisung. Mit use holt man Klassen aus anderen Namespaces herein, auf Wunsch unter einem kürzeren Namen.

<?php
declare(strict_types=1);

namespace App\Rechnung;

use App\Kunde\Kunde;
use Psr\Log\LoggerInterface as Log;

final class PdfErzeuger
{
    public function __construct(private Log $log) {}

    public function erzeugen(Kunde $kunde): string
    {
        $this->log->info('PDF erzeugt', ['kunde' => $kunde->id]);
        return \sprintf('Rechnung für %s', $kunde->name);
    }
}

Der vollständige Name dieser Klasse lautet App\Rechnung\PdfErzeuger. Der führende Backslash bei \sprintf verweist ausdrücklich auf die globale PHP-Funktion.

Autoloading: Klassen bei Bedarf laden

Ohne Autoloading müsste jedes Skript alle benötigten Dateien mit require einbinden. Mit spl_autoload_register() registriert man stattdessen eine Funktion, die PHP aufruft, sobald eine unbekannte Klasse, ein Interface, ein Trait oder ein Enum verwendet wird. Sie bekommt den Klassennamen und lädt die passende Datei.

<?php
spl_autoload_register(function (string $klasse): void {
    $praefix = 'App\\';
    $basis   = __DIR__ . '/src/';

    if (!str_starts_with($klasse, $praefix)) {
        return; // nicht zuständig, nächster Autoloader ist dran
    }
    $datei = $basis . str_replace('\\', '/', substr($klasse, strlen($praefix))) . '.php';
    if (is_file($datei)) {
        require $datei;
    }
});

spl_autoload_register() lässt sich mehrfach aufrufen. PHP fragt die registrierten Autoloader dann nacheinander, bis einer die Klasse geladen hat. In der Praxis haben große Anwendungen oft mehrere davon: den Composer-Autoloader für Bibliotheken, einen eigenen des CMS und weitere von Plugins oder Modulen. Für Admins bedeutet das: Welcher Code bei einer Anfrage tatsächlich geladen wird, ergibt sich aus dem Zusammenspiel aller dieser Autoloader und nicht allein aus der Ordnerstruktur.

Das Handbuch rät dringend davon ab, in einem Autoloader Exceptions zu werfen; PSR-4 verbietet es ausdrücklich. Die ältere Funktion __autoload() wurde mit PHP 7.2.0 als veraltet markiert und mit PHP 8.0.0 entfernt.

PSR-4: vom Klassennamen zum Dateipfad

PSR-4 ist ein Standard der PHP-FIG. Ein vollständiger Klassenname beginnt mit einem Hersteller-Namespace. Ein Präfix des Namespace wird einem Basisverzeichnis zugeordnet, der Rest des Namens ergibt Unterordner, und die Datei endet auf .php. Groß- und Kleinschreibung muss genau übereinstimmen. So sieht die Zuordnung in der composer.json aus:

{
    "autoload": {
        "psr-4": { "App\\": "src/" }
    }
}

Ein klassischer Stolperstein ist die Groß- und Kleinschreibung. Auf Entwicklungsrechnern mit Windows oder macOS unterscheidet das Dateisystem oft nicht zwischen Kunde.php und kunde.php, auf einem Linux-Server schon. Eine Anwendung, die lokal läuft, findet dann auf dem Server eine Klasse nicht. Die Regel aus PSR-4, Namen exakt in der richtigen Schreibweise zu verwenden, verhindert solche Überraschungen bei der Auslieferung.

Neben psr-4 kennt Composer classmap für Code ohne Standardstruktur und files für Dateien, die bei jeder Anfrage geladen werden, etwa Hilfsfunktionen. Weitere Standards der PHP-FIG beschreibt die Seite PSR-Standards.

Autoloader in der Produktion optimieren

In der Produktion sucht der Autoloader am besten nicht mehr im Dateisystem, sondern schlägt in einer fertigen Liste nach. Composer bietet dafür zwei Stufen:

1. composer install --no-dev --optimize-autoloader wandelt die PSR-4-Regeln in eine Klassenliste um. Das ist laut Composer-Dokumentation für die Produktion empfohlen.
2. --classmap-authoritative geht weiter: Klassen werden ausschließlich aus der Liste geladen. Nicht aufgeführte Dateien lädt der Autoloader dann gar nicht.
3. Bei jeder Auslieferung wird die Liste neu erzeugt, damit neue Klassen gefunden werden.

Autoloading und Sicherheit nach PHP2Shell

PHP2Shell betrifft den PHP-Interpreter, nicht den Autoloader. Pflicht bleiben das Update auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 und der Neustart aller Worker. Nach einem möglichen Vorfall verdient der Autoloader aber besondere Aufmerksamkeit: vendor/autoload.php und alle unter files eingetragenen Dateien werden bei jeder Anfrage ausgeführt. Eine dort eingeschleuste Zeile wirkt also auf der ganzen Website, ohne dass eine auffällige neue Datei im Upload-Ordner liegt.

Prüfen Sie deshalb, ob vendor und die Autoload-Dateien zum geprüften Stand aus der Versionsverwaltung passen. Hilfreich sind die Beiträge Kürzlich geänderte Dateien finden und CMS-Kerndateien mit dem Original vergleichen. Im Zweifel ist ein frisch erzeugtes vendor aus der Lock-Datei sicherer als jede Einzelreparatur.

Wie hilft PHP SOS konkret?

• Wir vergleichen vendor, Autoloader und Einstiegsdateien mit dem geprüften Stand und markieren jede Abweichung.
• Wir stellen den Paketbestand aus der Lock-Datei neu her und richten einen optimierten Autoloader ein.
• Wir prüfen, ob nur der öffentliche Ordner im Webroot liegt und Quellcode nicht direkt per URL erreichbar ist.
• Bei Befall übernehmen wir die Bereinigung im Rahmen der Malware-Entfernung und dokumentieren das Ergebnis.

Häufige Fragen

Quellen

• PHP-FIG: PSR-4 Autoloader
• PHP-Handbuch: Namespaces, Überblick
• PHP-Handbuch: Autoloading
• Composer: The composer.json schema