wake-up-neo.com

Bequeme Möglichkeit, wp_filesystem zu verwenden

Ich würde gerne$ wp_filesystemverwenden. Dies scheint die empfohlene Methode zu sein, um Dateisystemobjekte in WordPress zu bearbeiten, aber vergleiche dies:

plain PHP code:

mkdir('abc');

WP Dateisystem-API code:

$url = wp_nonce_url('plugins.php');
if (false === ($creds = request_filesystem_credentials($url, '', false, false, null) ) ) {
    echo "Could not create filesystem credentials";
    return;
}

if ( ! WP_Filesystem($creds) ) {
    request_filesystem_credentials($url, '', true, false, null);
    echo "Filesystem credentials were not available";
    return;
}

$wp_filesystem->mkdir('abc', true);

Das ist ein bisschen unhandlich und vielleicht stimmt etwas nicht, aber gibt es keine bequemere Möglichkeit, Methoden auf $wp_filesystem auszuführen? Ich habe versucht, den Code für die Anmeldeinformationen wegzulassen, aber in diesem Fall hat der Befehl filesystem nicht funktioniert.

3
Borek Bernard

Nein, bequemer geht es nicht.

Die Sache ist, dass Ihr erstes Beispiel auf den gängigsten Hosting-Systemen unsicher ist, da das Verzeichnis dem Benutzer "gehört", unter dem der Webserver selbst ausgeführt wird. Auf diese Weise kann jeder andere Benutzer, der Code auf demselben Webserver ausführen kann, darauf zugreifen, darauf schreiben, Dateien darin ändern usw.

Anmeldeinformationen sind erforderlich, um sicherzustellen, dass sich die Dateien im Besitz der richtigen Person befinden, und um zu verhindern, dass andere Benutzer auf demselben Server auf sie zugreifen können.

Zusätzliche Informationen, da die Kommentare dies zu benötigen scheinen:

In einer "normalen" Shared-Hosting-Konfiguration oder sogar auf einigen VPS-Hosting-Systemen wird der Webserver als ein anderer Benutzer ausgeführt als die Person, der die Dateien tatsächlich gehören. Meine WordPress-Installationsdateien befinden sich möglicherweise im Besitz von "otto", der Webserver wird jedoch möglicherweise unter dem Konto "Apache" ausgeführt.

Dies bedeutet, dass der WordPress-Code normalerweise als "Apache" -Benutzer ausgeführt wird, wenn er ausgeführt wird. Alle von ihm erstellten Dateien gehören auch "Apache" und nicht "otto". Darüber hinaus ist der "Apache" Account zwangsläufig eingeschränkt. Es ist möglicherweise nicht in der Lage, Dateien in meine Webverzeichnisse zu schreiben, oder es ist möglicherweise nicht in der Lage, die Dateien als Eigentum des richtigen "Otto" -Benutzers anzuzeigen. Dies ist alles aus Sicherheitsgründen, es sollte nicht diese Fähigkeiten haben.

Das WP_Filesystem erkennt dies und zeigt dem Benutzer ein Formular an, in dem er nach FTP-Anmeldeinformationen fragt. Dies ist, was der request_filesystem_credentials-Aufruf tatsächlich tut: Er führt diesen Test durch und generiert dann bei Bedarf ein Formular für den Benutzer. Der Benutzer gibt seine Informationen ein und überprüft damit beim nächsten Senden, ob der request_filesystem_credentials-Aufruf eine Verbindung zu sich selbst (Loopback, Sorta) über FTP herstellen kann.

Sehen Sie, wenn ich eine Datei über FTP erstelle, bin ich als ich verbunden, sodass die resultierende Datei im Besitz von "otto" ist. Mit diesem Mechanismus kann das WP_Filesystem Dateien als der richtige Benutzer erstellen, obwohl es als "Apache" ausgeführt wird. Diese Anmeldeinformationen sind daher erforderlich, und Sie müssen den Benutzer nach ihnen fragen. Das einfache Erstellen von Dateien und Verzeichnissen mit normalen PHP Methoden kann zu einer Sicherheitslücke führen, insbesondere beim Shared Hosting.

Auf einem gemeinsam genutzten Host haben andere Personen Konten auf demselben Computer. Sie führen ihren Code mit denselben Webserver-Prozessen aus. Und dieser Code läuft auch als "Apache". Wenn ich also Verzeichnisse und Dateien im Besitz von "Apache" habe, können andere Benutzer ihren Code als "Apache" ausführen und meine Dateien ändern. Das ist ein Problem. Dass die Dateien mir gehören und nicht "Apache", verhindert das.

Auf einigen der gebräuchlichsten gemeinsam genutzten Hosting-Systeme wird beim Aufruf von request_filesystem_credentials kein Formular mehr angezeigt. Stattdessen wird einfach true zurückgegeben und der WP_Filesystem-Code wird fortgesetzt. Dies geschieht, wenn ein Hosting-System mit einer Konfiguration ausgeführt wird, die als "setuid" oder "suphp" bezeichnet wird.

In einer Setuid-Konfiguration wird der Webserver als "Apache" oder was auch immer ausgeführt, aber der PHP -Prozess, den er für die Verarbeitung einer Anfrage startet, legt fest, dass sein eigener Benutzer/Besitzer mit dem Besitzer des PHP -Datei, die anfänglich ausgeführt wird. Wenn der PHP-Prozess ausgeführt wird und die ursprüngliche WordPress-Datei index.php (oder eine beliebige andere Datei) geladen wird, wird angezeigt, dass die Datei im Besitz von "otto" ist, und das eigene Benutzerkonto wird für diesen bestimmten Lauf auf "otto" gesetzt.

Viele Shared Hosting-Anbieter nehmen diese Konfiguration vor, da sie für diesen Fall tatsächlich sicherer ist. Wenn der PHP-Prozess als Benutzerkonto ausgeführt wird, ist er nicht mehr "Apache" und kann nicht auf Dateien in den Konten anderer Personen zugreifen. Es kann nur auf die Dateien des Kontos zugreifen, auf das es Zugriff haben soll. Als netter Nebeneffekt bedeutet dies, dass der request_filesystem_credentials-Aufruf seinen Test durchführt und feststellt, dass a) Ja, er Dateien schreiben kann und b) diese Dateien dem richtigen Benutzer gehören, da der Benutzer des Prozesses nun auf den gleichen Wert eingestellt ist als Eigentümer der Dateien. In diesem Fall wird der Modus "Direkt" verwendet, request_filesystem_credentials gibt true zurück und dem Benutzer wird kein Formular für FTP-Anmeldeinformationen angezeigt.

Beachten Sie, dass solche setuid-Methoden auf nicht gemeinsam genutzten Hosting-Konten weniger sicher sind. Wenn es nur einen Webbenutzer gibt, muss setuid nicht ausgeführt werden, um andere Webbenutzer auf demselben Server zu schützen. Bei VPS-Hosting und ähnlichen Anwendungen ist dieses Setup nicht so häufig und es ist allgemein üblich, FTP-Anmeldeinformationen zu benötigen. Dies ist sicherer, da ein Angreifer, selbst wenn er die Ausführung von Code durch das System veranlassen kann, möglicherweise keine Dateien mit diesem Code ändern kann, da er nicht als korrekter Prozess ausgeführt wird.

Sicherheit ist komplex. Das WP_Filesystem ist grundsätzlich eine Sicherheitssache, und Sie sollten es verwenden, wenn Sie Dateien in der Installation bearbeiten müssen. Und ja, manchmal bedeutet dies, dass Sie ein Anmeldeinformationsformular anzeigen müssen. Ich schlage vor, damit umzugehen, da alles andere ein potenzielles Sicherheitsrisiko darstellt, das Sie nicht einfach wegwischen sollten, nur weil es etwas unangenehm ist.

4
Otto