Bequeme Art, wp_filesystem zu verwenden

Ich würde gerne $ wp_filesystem verwenden, was die empfohlene Methode zur Manipulation von Dateisystemobjekten in WordPress zu sein scheint, aber folgendes vergleichen:

einfacher 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); 

Dies ist ein wenig unhandlich und vielleicht bekomme ich etwas falsch, aber gibt es keinen bequemeren Weg, Methoden auf $wp_filesystem ? Ich habe versucht, den Berechtigungsnachweis zu verlassen, aber in diesem Fall hat der Dateisystembefehl nicht funktioniert.

Solutions Collecting From Web of "Bequeme Art, wp_filesystem zu verwenden"

Nein, es gibt keinen bequemeren Weg.

Die Sache ist, Ihr erstes Beispiel ist unsicher auf den meisten gängigen Hosting-Systemen, da das Verzeichnis “Besitzer” von welchem ​​Benutzer der Webserver selbst ist, als sein wird. Somit kann jeder, der Code auf demselben Webserver ausführen kann, darauf zugreifen, darauf schreiben, Dateien darin ändern und so weiter.

Anmeldeinformationen sind erforderlich, um sicherzustellen, dass die Dateien der richtigen Person gehören, sodass sie nicht von anderen Benutzern auf demselben Server verwendet werden können.

Zusätzliche Infos, weil die Kommentare es zu brauchen scheinen:

Bei einer “standardmäßigen” Shared-Hosting-Konfiguration oder sogar bei einigen VPS-Hosting-Systemen läuft der Webserver als anderer Benutzer als die Person, der die Dateien tatsächlich gehören. Also, meine WordPress-Installationsdateien gehören möglicherweise “otto”, aber der Webserver läuft möglicherweise unter dem “apache” -Konto.

Dies bedeutet, dass wenn der WordPress-Code ausgeführt wird, er normalerweise als “Apache” -Benutzer ausgeführt wird. Alle Dateien, die erstellt werden, gehören ebenfalls zu “apache”, nicht zu “otto”. Außerdem ist das “Apache” -Konto notwendigerweise begrenzt. 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 den Eigentümern des richtigen “Otto” -Benutzers zuzuordnen. Dies ist alles aus Sicherheitsgründen, sollte es diese Fähigkeiten nicht haben.

Das WP_Filesystem erkennt, wann dies der Fall ist, und zeigt dann dem Benutzer ein Formular an, in dem nach FTP-Anmeldeinformationen gefragt wird. Dies ist der Aufruf von request_filesystem_credentials : Er führt diesen Test durch und generiert bei Bedarf ein Formular für den Benutzer. Der Benutzer gibt seine Informationen ein, und beim nächsten request_filesystem_credentials kann der Aufruf request_filesystem_credentials prüfen, ob er sich über FTP mit sich selbst (loopback, sorta) verbinden kann.

Siehe, wenn ich eine Datei über FTP erstelle, dann bin ich als ich verbunden, also gehört die entstehende Datei zu “otto”. Mit diesem Mechanismus kann das WP_Filesystem Dateien als den richtigen Benutzer erstellen, obwohl es als “Apache” ausgeführt wird. Diese Anmeldeinformationen sind also notwendig und ja, Sie müssen den Benutzer nach ihnen fragen. Einfaches naives Erstellen von Dateien und Verzeichnissen mit normalen PHP-Methoden kann zu einem Sicherheitsproblem führen, insbesondere bei Shared Hosting.

Auf einem freigegebenen Host haben andere Personen Konten auf demselben Computer. Sie führen ihren Code mit denselben Webserverprozessen aus. Und dieser Code läuft auch als “Apache”. Also, wenn ich Verzeichnisse und Dateien im Besitz von “Apache” habe, können andere Leute ihren Code als “Apache” ausführen und meine Dateien ändern. Das ist ein Problem. Wenn ich die Dateien besitze und nicht “Apache”, verhindere das.

Auf einigen der gebräuchlichsten Shared-Hosting-Systeme werden Sie feststellen, dass das request_filesystem_credentials Aufrufs request_filesystem_credentials ein Formular nicht request_filesystem_credentials . Stattdessen wird einfach true zurückgegeben und der WP_Filesystem-Code wird fortgesetzt. Dies geschieht, wenn ein Hosting-System mit einer Konfiguration namens “setuid” oder “suphp” läuft.

In einer setuid-Konfiguration läuft der Webserver als “Apache” oder was auch immer, aber der PHP-process, den er zur Bearbeitung einer Anfrage hervorbringt, setzt seinen eigenen Benutzer / Besitzer gleich dem Besitzer der PHP-Datei, die er anfänglich ausführt. Wenn der php-process ausgeführt wird und die ursprüngliche WordPress index.php-Datei (oder eine andere Datei) geladen wird, sieht er, dass die Datei “otto” gehört und setzt daher für diesen bestimmten Lauf ein eigenes Benutzerkonto auf “otto”.

Viele Shared Hosting Provider nehmen diese Konfiguration vor, da sie für diesen Fall tatsächlich sicherer sind. Wenn der PHP-process als Benutzerkonto ausgeführt wird, ist es nicht mehr “apache” und kann nicht auf Dateien in den Konten anderer Personen zugreifen. Es kann nur auf die Dateien für das Konto zugreifen, auf das es zugreifen soll. Als netten Nebeneffekt bedeutet dies, dass der Aufruf request_filesystem_credentials seinen Test durchführt und feststellt, dass a) Ja Dateien schreiben kann und b) diese Dateien dem richtigen Benutzer gehören, da der Benutzer des processes jetzt auf denselben request_filesystem_credentials gesetzt ist als der Besitzer der Dateien. In diesem Fall wird der Modus “direct” verwendet, request_filesystem_credentials gibt “true” zurück, und dem Benutzer wird kein Formular für FTP-Anmeldeinformationen angezeigt.

Beachten Sie, dass setuid-Methoden wie diese in nicht gemeinsam genutzten Hosting-Accounts weniger sicher sind. Wenn nur ein Webbenutzer vorhanden ist, muss setuid nicht ausgeführt werden, um andere Webbenutzer auf demselben Server zu schützen. Bei VPS-Hosting und ähnlichem ist dieses Setup nicht so üblich und FTP-Anmeldedaten sind an der Tagesordnung. Dies ist sicherer, denn selbst wenn ein Angreifer das System zur Ausführung von Code veranlassen könnte, ist es möglicherweise nicht möglich, dass dieser Code Dateien ändern kann, da er nicht als korrekter process ausgeführt wird.

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