web-dev-qa-db-fra.com

Manière pratique d'utiliser wp_filesystem

J'aimerais utiliser$ wp_filesystemqui semble être le moyen recommandé pour manipuler les objets du système de fichiers dans WordPress, mais comparons ceci:

plain PHP code:

mkdir('abc');

WP API de système de fichiers 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);

C'est un peu difficile à manier et peut-être que je me trompe, mais n'y a-t-il pas un moyen plus pratique d'exécuter des méthodes sur $wp_filesystem? J'ai essayé de laisser le code d'identification, mais dans ce cas, la commande du système de fichiers ne fonctionnait pas.

filesystemwp-filesystem
3
Borek Bernard

Non, il n'y a pas de moyen plus pratique.

Le fait est que votre premier exemple n'est pas sécurisé sur les systèmes d'hébergement les plus courants car le répertoire sera "possédé" par l'utilisateur, quel que soit l'utilisateur sur lequel le serveur Web s'exécute. Ainsi, toute autre personne capable d'exécuter du code sur le même serveur Web pourra y accéder, y écrire, y modifier des fichiers, etc.

Les informations d'identification sont nécessaires pour garantir que les fichiers appartiennent à la personne appropriée, ce qui les empêche d'être accessibles aux autres utilisateurs sur le même serveur.

Informations supplémentaires car les commentaires semblent en avoir besoin:

Sur une configuration d'hébergement partagé "standard", ou même sur certains systèmes d'hébergement VPS, le serveur Web s'exécute en tant qu'utilisateur différent de la personne qui détient réellement les fichiers. Ainsi, mes fichiers d'installation WordPress peuvent appartenir à "otto", mais le serveur Web s'exécute peut-être sous le compte "Apache".

Cela signifie que lorsque le code WordPress est en cours d'exécution, il s'exécute généralement en tant qu'utilisateur "Apache". Tous les fichiers créés seront également détenus par "Apache" et non par "otto". De plus, le compte "Apache" est nécessairement limité. Il se peut qu'il ne soit pas du tout capable d'écrire des fichiers dans mes répertoires Web, ou qu'il ne soit pas possible de chown les fichiers appartenant à l'utilisateur "otto" approprié. Tout cela pour des raisons de sécurité, il ne devrait pas avoir ces capacités.

Le WP_Filesystem détecte quand c'est le cas, puis affichera un formulaire à l'utilisateur demandant des informations d'identification FTP. C’est ce que fait réellement l’appel request_filesystem_credentials: Il effectue ce test, puis génère un formulaire pour l’utilisateur si nécessaire. L'utilisateur entre ses informations et, lors de la prochaine soumission, l'appel request_filesystem_credentials peut vérifier s'il peut se reconnecter à lui-même (bouclage, sorte) via FTP.

Vous voyez, lorsque je crée un fichier via FTP, je suis connecté en tant que moi, le fichier résultant appartient donc à "otto". À l'aide de ce mécanisme, WP_Filesystem peut créer des fichiers en tant qu'utilisateur correct même s'il s'exécute en tant qu '"Apache". Ces informations d'identification sont donc nécessaires et, oui, vous devez les demander à l'utilisateur. La création naïve de fichiers et de répertoires à l’aide de méthodes PHP normales peut poser un problème de sécurité, en particulier pour l’hébergement partagé.

Sur un hôte partagé, d'autres personnes ont des comptes sur le même ordinateur. Ils exécutent leur code en utilisant les mêmes processus de serveur Web. Et ce code fonctionne aussi comme "Apache". Donc, si j’ai des répertoires et des fichiers appartenant à "Apache", d’autres personnes pourront exécuter leur code en tant que "Apache" et modifier mes fichiers. C'est un problème. Avoir les fichiers que je possède et non pas "Apache" empêche cela.

Maintenant, sur certains des systèmes d'hébergement partagé les plus courants, vous constaterez que l'appel request_filesystem_credentials n'apparaît pas dans un formulaire. Au lieu de cela, il renvoie simplement true et le code WP_Filesystem continue. Cela se produit lorsqu'un système d'hébergement fonctionne avec une configuration appelée "setuid" ou "suphp".

Dans une configuration setuid, le serveur Web s'exécute sous le nom "Apache" ou autre, mais le processus PHP qu'il génère pour gérer une requête définit son propre utilisateur/propriétaire comme identique au propriétaire du PHP fichier qu'il exécute initialement. Ainsi, lorsque le processus php s'exécute et charge le fichier WordPress index.php initial (ou un fichier quelconque), il voit que le fichier appartient à "otto" et définit donc son propre compte utilisateur sur "otto" pour cette exécution particulière.

De nombreux fournisseurs d'hébergement partagé effectuent cette configuration car elle est en réalité plus sécurisée pour ce cas. Si le processus php s'exécute en tant que compte d'utilisateur, il ne s'agit plus de "Apache" et ne peut pas accéder aux fichiers des comptes d'autres personnes. Il ne peut accéder aux fichiers que du compte auquel il est censé avoir accès. En tant qu'effet secondaire sympa, cela signifie que l'appel request_filesystem_credentials effectue son test et découvre a) que oui, il peut écrire des fichiers et que b) ces fichiers seront détenus par le bon utilisateur, car l'utilisateur du processus est maintenant défini sur le même en tant que propriétaire des fichiers. Dans ce cas, le mode "direct" est utilisé, request_filesystem_credentials renvoie true et aucun formulaire n'est affiché à l'utilisateur pour les informations d'identification FTP.

Notez que les méthodes setuid telles que celle-ci sont en réalité moins sécurisées sur les comptes d'hébergement non partagés. Lorsqu'il n'y a qu'un seul utilisateur Web, il n'est pas nécessaire de définir setuid pour protéger les autres utilisateurs Web sur le même serveur. Ainsi, sur l’hébergement VPS et similaires, cette configuration n’est pas aussi commune et il est courant d’exiger des informations d’identification FTP. Ceci est plus sécurisé car même si un attaquant peut faire exécuter du code par le système, il se peut qu’il ne puisse pas lui demander de modifier les fichiers car il ne s’exécute pas comme le processus correct.

La sécurité est complexe. WP_Filesystem est fondamentalement un élément de sécurité et vous devez l’utiliser si vous devez manipuler des fichiers dans l’installation. Et oui, cela signifie parfois que vous devez afficher un formulaire d'informations d'identification. Je suggère d'y faire face, parce que toute autre chose représente un risque potentiel pour la sécurité qu'il ne faut pas tout simplement effacer, simplement parce que c'est un peu désagréable.

4
Otto