Mise à niveau de Wordpress 4.0 demande un mot de passe FTP
J'ai pu mettre à jour Wordpress 4.0 sur ma machine locale et je viens également de mettre à jour des plugins sur la machine de production, mais lorsque j'essaie de mettre à jour Wordpress 4.0 sur la machine de production, il demande mes informations d'identification FTP. Pourquoi demande-t-il cela alors qu'il n'en a jamais eu besoin auparavant?
CloudFlare pourrait-il avoir quelque chose à voir avec cela?
J'ai trouvé ceci http://codex.wordpress.org/Dashboard_Updates_Screen#Troubleshooting
J'ai essayé d'utiliser chown -R Apache:apache * sur l'installation de Wordpress, mais il demande toujours des informations d'identification FTP. Je ne veux pas configurer le serveur FTP. Pourquoi aurait-il besoin du serveur FTP lors de la récupération?
Je devais également changer le propriétaire du répertoire Web racine.
chown Apache:apache . # or chown Apache:apache /var/www/html
Edit by Otto: Chloé, comme vous avez demandé plus d’informations que je ne pourrais raisonnablement en dire dans un commentaire, je l’ajoute à votre réponse. J'espère que ça va. Si ce n'est pas le cas, n'hésitez pas à l'inverser ou à me le faire savoir et je le ferai.
La raison pour laquelle j'ai mentionné qu'il s'agissait d'un problème de sécurité est liée à la propriété du fichier, à la limitation des autorisations et à la limitation de l'accès.
Unix comme les systèmes contiennent le concept de "propriétaires" et "autorisations". Les fichiers appartiennent à un compte d'utilisateur et disposent d'autorisations pour contrôler s'ils sont en lecture, en écriture ou exécutables par d'autres comptes. Il s’agit par nature d’une fonctionnalité de sécurité visant à empêcher d’autres comptes de pouvoir écrire dans vos fichiers, voire à leur permettre de le faire.
Les programmes en cours ont aussi des "propriétaires". Ces programmes héritent des capacités d'autorisation de leur propriétaire. Si vous exécutez un programme, il peut faire tout ce que vous pouvez, mais ne pourra rien faire que vous ne puissiez pas, car il est "détenu" par votre compte utilisateur.
En ce qui concerne les serveurs Web, vous autorisez essentiellement le monde extérieur à exécuter un programme sur votre ordinateur. Pour cette raison, la propriété est importante et la plupart des serveurs Web fonctionnent donc en tant qu'utilisateur "www" ou, dans le cas du serveur Web Apache, en tant qu'utilisateur "Apache".
Si quelqu'un parvient à se frayer un chemin dans un programme exécuté sur votre site Web, il en prendra le contrôle, mais restera limité par les capacités de ce programme. S'ils piratent un processus exécuté par "Apache", leur utilisateur sera "Apache" et ils n'auront accès qu'en tant que compte d'utilisateur "Apache".
Par conséquent, le fait que vos fichiers appartiennent à "Apache" est un problème de sécurité, car vous dites essentiellement que quiconque dans le monde est propriétaire de ces fichiers. Quiconque passe par cette porte peut les voir, les éditer, les modifier.
D'autre part, si le compte d'utilisateur qui possédait les fichiers était "utilisateur" et que "Apache" était autorisé à lire les fichiers, mais pas à y écrire, le serveur Web pourrait toujours exécuter son travail. Il pourrait lire les fichiers, exécuter les scripts PHP, faire tout ce qu'il est censé faire ... mais ne pas modifier les fichiers.
C'est pourquoi WordPress demande des informations d'identification FTP. Lorsqu'il se met à jour automatiquement, il constate que les fichiers WP appartiennent à "l'utilisateur", mais WordPress s'exécute en tant que "Apache". Ainsi, il ne peut pas mettre à jour correctement sans changer le propriétaire. L'utilisateur "Apache" ne peut pas écrire les fichiers appartenant à "utilisateur". Il n'a pas cette permission. Plus précisément, WordPress doit créer de nouveaux fichiers et également supprimer les anciens. Donc, si cela se produit lors de l'exécution en tant qu '"Apache", les nouveaux fichiers seront la propriété de "Apache", alors qu'ils devraient appartenir à "utilisateur". Il arrête intentionnellement la mise à jour à ce stade car il ne peut pas créer de fichiers avec la propriété correcte.
Demander FTP est une seconde approche. Il peut se reconnecter à son propre serveur via FTP et, en utilisant ces informations d'identification, il peut écrire des fichiers en tant qu'utilisateur correct ... Pour cette fois seulement. Après la déconnexion, les informations d'identification sont oubliées. Coffre-fort tout autour.
En d'autres termes, lorsque vous entrez des informations FTP, vous donnez des informations d'identification de sécurité WordPress pour pouvoir modifier les fichiers une fois. En rendant les fichiers appartenant à "Apache" à la place, vous donnez à WordPress la possibilité de modifier les fichiers à tout moment, sans informations d'identification supplémentaires. Vous avez contourné la fonctionnalité de sécurité ici, où, comme auparavant, WordPress ne pouvait pas modifier les fichiers sans vos informations de connexion, maintenant il le peut. C'est un problème.
Maintenant, vous n’exécutez peut-être pas le service FTP normalement. Peut-être que vous utilisez uniquement SSH. Ça va aussi. Dans ce cas, envisagez d'ajouter l'extension PHP SSH2 à la configuration _ de votre serveur PHP. Si WordPress constate que, au lieu de FTP uniquement, vous aurez également la possibilité de choisir SFTP, qui utilise la connexion SSH pour s’authentifier et copier les fichiers. Les mêmes principes s'appliquent, c'est d'essayer d'écrire des fichiers avec la propriété correcte pour éviter les problèmes de sécurité.
La sécurité n'est pas une chose binaire, elle a des couches. Si une personne obtient un accès non autorisé, la configuration correcte des choses peut aider à limiter le nombre de dommages possibles. La propriété des fichiers et des processus est un niveau de sécurité assez bas dans les systèmes de type Unix, mais il en reste un important.
Essayez les étapes suivantes et cela vous permettra probablement de tout mettre à jour.
- Ouvrez wp-config.php et ajoutez `
define('FS_METHOD','direct');
- La dernière étape consiste à changer le propriétaire owner: group du répertoire que vous avez déjà créé. Remarque rapide, si vous utilisez Apache2, le groupe est www-data et non Apache. Donc ce serait comme ça
Sudo chown -R <user>:www-data <WordPress-directory>
Esperons que ça marche.
Il existe une approche encore plus sécurisée pour configurer votre Wordpress qui n’implique aucun mot de passe: utilisez SFTP.
En gros, vous devrez faire quelques réglages et vous devrez être connecté en tant qu'utilisateur ftp Wordpress et dans son répertoire personnel.
Commencez par créer une paire de clés PKI (keygen-ssh vous guide tout au long du processus. Cet exemple suppose que vous avez pris toutes les valeurs par défaut):
keygen-ssh
Placez les nouvelles clés là où ils doivent aller:
cat ip_rsa.pub >> .ssh/authorized_keys
mv ip_rsa* .ssh/
Changez les protections (on ne sait pas pourquoi Wordpress exige cela, mais c'est le cas):
chmod 700 .ssh/
chmod 600 .ssh/*
Ajoutez les lignes suivantes à votre fichier wp-config.php:
define('FTP_Host', 'localhost');
define('FTP_USER', '«your user name goes here»');
define('FTP_PUBKEY', '«full path to user's home directory»/.ssh/wp_rsa.pub');
define('FTP_PRIKEY', '«full path to user's home directory»/.ssh/wp_rsa');
Assurez-vous qu'Apache peut accéder au répertoire wp-content /:
chmod 775 «full path to WordPress directory»/wp-content
J'ai décrit en détail le processus complet dans une publication sur mon blog .
"CloudFlare pourrait-il avoir quelque chose à voir avec cela?"
CloudFlare ne proxy pas le trafic ftp et cela va généralement être quelque chose à prendre avec votre fournisseur d'hébergement.
Le problème est que votre serveur exécute un protocole PHP différent de celui utilisé par WordPress, je ne sais pas comment cela se passe. Vous pouvez vérifier le protocole PHP que vous utilisez en consultant phpinfo () pour une ligne d'API SERVEUR. Ou si cPanel est hébergé sur votre hébergement, vous pouvez voir Comment activer suPHP dans cPanel .
Vous faites une solution de contournement avec les détails FTP dans wp-config.php comme ceci:
define('FTP_USER', 'username');
define('FTP_PASS', 'password');
define('FTP_Host', 'ftp.example.org:21');
Vous pouvez également définir FTP_SSL, FTP_BASE, FTP_CONTENT_DIR et FS_METHOD si vous en avez besoin.