Удобный способ использования файловой системы wp
Я хотел бы использовать $wp_filesystem, который, по-видимому, является рекомендуемым способом управления объектами файловой системы в WordPress, но сравните это:
Простой PHP-код:
mkdir('abc');
$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);
Это немного громоздко, и, возможно, я что-то не так понимаю, но нет ли более удобного способа выполнения методов на $wp_filesystem? Я попытался оставить код учетных данных, но в этом случае команда файловой системы не сработало.
1 answers
Нет, более удобного способа нет.
Дело в том, что ваш первый пример небезопасен в наиболее распространенных системах хостинга, потому что каталог будет "принадлежать" любому пользователю, от имени которого работает сам веб-сервер. Таким образом, любой другой пользователь, способный выполнять код на том же веб-сервере, сможет получить к нему доступ, записывать на него, изменять файлы в нем и так далее.
Учетные данные необходимы для обеспечения того, чтобы файлы принадлежали правильному лицу, предотвращая их доступ к другим пользователям на том же сервере.
Дополнительная информация, потому что комментарии, похоже, нуждаются в ней:
В "стандартной" конфигурации общего хостинга или даже в некоторых системах хостинга VPS веб-сервер работает от имени пользователя, отличного от пользователя, которому фактически принадлежат файлы. Итак, мои установочные файлы WordPress могут принадлежать "отто", но веб-сервер может работать под учетной записью "apache".
Это означает, что когда код WordPress запущен, он обычно выполняется как пользователь "apache". Любые файлы, которые он создает, также будут принадлежать "apache", а не "otto". Кроме того, учетная запись "apache" обязательно ограничена. Возможно, у него вообще нет возможности записывать файлы в мои веб-каталоги, или у него может не быть возможности передавать файлы, принадлежащие соответствующему пользователю "otto". Это все по соображениям безопасности, у него не должно быть таких способностей.
Файловая система WP_Filesystem определяет, когда это так, и затем отобразит форму для пользователя, запрашивающего FTP полномочия. Это то, что на самом деле делает вызов request_filesystem_credentials: он выполняет этот тест, а затем при необходимости создает форму для пользователя. Пользователь вводит свою информацию, и, используя ее, при следующей отправке вызов request_filesystem_credentials может проверить, может ли он подключиться к самому себе (замкнутый цикл, своего рода) через FTP.
Видите ли, когда я создаю файл по FTP, я подключаюсь как я, поэтому результирующий файл принадлежит "отто". Используя этот механизм, WP_Filesystem может создавать файлы как правильный пользователь, даже если он работает как "apache". Таким образом, эти учетные данные необходимы, и да, вы должны запросить их у пользователя. Простое наивное создание файлов и каталогов с использованием обычных методов PHP может привести к проблемам с безопасностью, особенно на общем хостинге.
На общем хостинге у других пользователей есть учетные записи на той же машине. Они запускают свой код, используя те же процессы веб-сервера. И этот код тоже работает как "apache". Итак, если у меня есть каталоги и файлы, принадлежащие "apache", то другие люди могут запускать свои кодируйте как "apache" и изменяйте мои файлы. Это проблема. Наличие файлов, принадлежащих мне, а не "apache", предотвращает это.
Теперь, в некоторых из наиболее распространенных систем общего хостинга, вы обнаружите, что вызов request_filesystem_credentials на самом деле не выводит форму. Вместо этого он просто возвращает true, и код WP_Filesystem продолжается. Это происходит, когда хостинговая система работает с конфигурацией, известной как "setuid" или "suphp".
В конфигурации setuid веб-сервер работает как "apache" или как бы то ни было, но процесс PHP, который он порождает для обработки запроса, устанавливает своего собственного пользователя/владельца таким же, как и владелец PHP-файла, который он изначально запускает. Поэтому, когда запускается процесс php и загружается начальный WordPress index.php файл (или любой другой файл), он видит, что файл принадлежит "отто", и поэтому он устанавливает для своей учетной записи пользователя значение "отто" для этого конкретного запуска.
Многие провайдеры общего хостинга выполняют эту настройку, потому что в этом случае она на самом деле более безопасна. Если php процесс запускается от имени учетной записи пользователя, тогда он больше не является "apache" и не может получить доступ к файлам в учетных записях других людей. Он может получить доступ только к файлам для учетной записи, к которой у него должен быть доступ. В качестве приятного побочного эффекта это означает, что вызов request_filesystem_credentials выполняет свой тест и обнаруживает, что а) да, он может записывать файлы и б) эти файлы будут принадлежать правильному пользователю, потому что пользователь процесса теперь настроен так же, как владелец файлов. В этом случае используется режим "прямой", request_filesystem_credentials возвращает значение true, и пользователю не отображается форма для ввода учетных данных FTP.
Обратите внимание, что подобные методы setuid на самом деле менее безопасны для учетных записей хостинга, не являющихся общими. Когда есть только один веб-пользователь, тогда нет необходимости использовать setuid для защиты других веб-пользователей на том же сервере. Так что на VPS-хостинге и тому подобном эта настройка не так распространена, и требование учетных данных FTP является обычным делом. Это более безопасно, потому что даже если злоумышленник может заставить систему выполнить код, они могут не быть возможность изменить этот код в любых файлах, потому что он выполняется не как правильный процесс.
Безопасность сложна. Файловая система WP_Filesystem - это, по сути, система безопасности, и вы должны использовать ее, если вам нужно манипулировать файлами при установке. И да, иногда это означает, что вам нужно отобразить форму учетных данных. Я предлагаю справиться с этим, потому что все остальное представляет собой потенциальную угрозу безопасности, которую вы не должны просто устранять только потому, что это несколько неприятно.