web-dev-qa-db-ja.com

Wp_filesystemを使うための便利な方法

私は$ wp_filesystemを使いたいのですが、これはWordPressでファイルシステムオブジェクトを操作するのに推奨される方法のようですが、これを比較してください。

プレーンPHPコード：

mkdir('abc');

WPファイルシステムAPI コード：

$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上でメソッドを実行するためのもっと便利な方法はありませんか。認証情報コードを除外しようとしましたが、その場合、filesystemコマンドが機能しませんでした。

filesystemwp-filesystem
3
Borek Bernard

いいえ、もっと便利な方法はありません。

問題は、あなたの最初の例は最も一般的なホスティングシステムでは安全ではないということです。なぜなら、ディレクトリはウェブサーバ自体が走っているどのユーザによっても "所有"されるからです。したがって、その同じWebサーバー上でコードを実行できる他のユーザーは、アクセスしたり、書き込んだり、ファイルを変更したりすることができます。

資格情報は、ファイルが正しいユーザーによって所有されていることを確認し、同じサーバー上の他のユーザーからアクセスされるのを防ぐために必要です。

コメントに必要と思われるための追加情報

「標準の」共有ホスティング設定、あるいはいくつかのVPSホスティングシステムでさえ、Webサーバは実際にファイルを所有する人とは異なるユーザとして実行されています。だから、私のWordPressのインストールファイルは "otto"が所有しているかもしれませんが、ウェブサーバーは "Apache"アカウントの下で動いているかもしれません。

つまり、WordPressコードが実行されているときは、通常「Apache」ユーザーとして実行されています。それが作成したファイルも、 "otto"ではなく "Apache"が所有します。さらに、「Apache」アカウントは必然的に制限されています。それは私のウェブディレクトリにファイルを書く能力を全く持っていないかもしれません、あるいはそれは適切な "otto"ユーザによって所有されるためにファイルをchownする能力を持っていないかもしれません。これはすべてセキュリティ上の理由からです。これらの機能を持つべきではありません。

WP_Filesystemはこれが事実であることを検出してから、FTP資格情報を要求するフォームをユーザーに表示します。これがrequest_filesystem_credentials呼び出しが実際に行うことです。これはそのテストを実行し、必要に応じてユーザー用のフォームを生成します。ユーザーは自分の情報を入力し、それを使用して、次回の送信時にrequest_filesystem_credentials呼び出しはFTP経由で自分自身に接続できるかどうか（loopback、sorta）を確認できます。

FTPでファイルを作成すると、自分が接続しているので、結果のファイルは "otto"が所有しています。このメカニズムを使うことで、WP_Filesystemは "Apache"として実行されていても正しいユーザーとしてファイルを作成することができます。したがって、それらの資格情報は必要であり、そうです、あなたはユーザーにそれらを尋ねなければなりません。通常のPHPメソッドを使用して単純にファイルやディレクトリを作成すると、特に共有ホスティングではセキュリティ上の問題が発生する可能性があります。

共有ホストでは、他の人が同じマシン上にアカウントを持っています。彼らは、同じWebサーバープロセスを使ってコードを実行しています。そしてそのコードは "Apache"としても動作します。ですから、私が "Apache"が所有するディレクトリとファイルがあれば、他の人々は自分のコードを "Apache"として実行して私のファイルを変更することができます。それは問題だ。 「Apache」ではなく、私が所有しているファイルを持つことでそれを防ぐことができます。

さて、最も一般的な共有ホスティングシステムのいくつかでは、request_filesystem_credentials呼び出しを行っても実際にはフォームがポップアップしないことがわかります。代わりに、単にtrueを返し、WP_Filesystemコードは続行します。これは、ホスティングシステムが "setuid"または "suphp"として知られる設定で実行されているときに起こります。

Setuid設定では、Webサーバは "Apache"またはその他のものとして動作しますが、リクエストを処理するために生成されるPHPプロセスは、自身のユーザ/所有者をPHPファイル。そのため、phpプロセスが実行され、最初のWordPressのindex.phpファイル（またはどんなファイルでも）がロードされると、そのファイルは "otto"によって所有されていると見なされ、その特定の実行に対して自身のユーザーアカウントは "otto"に設定されます。

多くの共有ホスティングプロバイダがこの設定を行っています。なぜならそれは実際にはより安全だからです。 phpプロセスがユーザーアカウントとして実行されている場合、それはもう「Apache」ではなく、他の人のアカウントのファイルにアクセスすることはできません。アクセス権があるはずのアカウントのファイルにのみアクセスできます。 Niceの副作用として、これはrequest_filesystem_credentials呼び出しがテストを実行して、a）ファイルを書き込めること、そしてb）それらのファイルが正しいユーザーによって所有されることを確認したことを意味します。ファイルの所有者として。その場合は、「直接」モードが使用され、request_filesystem_credentialsはtrueを返し、ユーザーにはFTP資格情報のためのフォームは表示されません。

このようなsetuidメソッドは、非共有ホスティングアカウントでは実際には安全性が低くなります。 Webユーザーが1人だけの場合は、同じサーバー上の他のWebユーザーを保護するためにsetuidを実行する必要はありません。そのため、VPSホスティングなどでは、この設定はそれほど一般的ではなく、FTP認証情報を要求するのが一般的です。攻撃者がシステムにコードを実行させることができても、正しいプロセスとして実行されていないため、そのコードにファイルを変更させることができない可能性があるため、これはより安全です。

セキュリティは複雑です。 WP_Filesystemは基本的にセキュリティ上の問題であり、インストールでファイルを操作する必要がある場合はそれを使用する必要があります。そして、そう、時々これはあなたが信任状フォームを表示する必要があることを意味します。それ以外のものはセキュリティ上のリスクがあるため、単に拭いてはいけないというのはやや不快だからです。

4
Otto