1

WPI経由でインストールされたWin2k8/IIS7（httpcache、fastCgi、UrlRewriter 2.0を使用）でWordPressを実行しています。すべてが正常に機能しているようです（アップロード、Live Writerを介した投稿、コメント、プラグイン、きれいなURL）。

WordPressを最新バージョンに更新しようとしていますが、次のようなエラーが発生します。

ダウンロードに失敗しました。ファイルストリーミングの宛先ディレクトリが存在しないか、書き込み可能ではありません

これは、テーマをダウンロードしたり、プラグインを更新したりしようとしたときに発生するエラーと同じです。

イベントログにエラーはなく、WordPressは、探しているディレクトリ、使用していると思われるユーザー、または不足している権限を実際に教えてくれません。

IIS App Poolユーザーが明示的に設定されていること、ディレクトリにそのユーザーの変更アクセス許可があること、そして最後にそれらのアクセス許可がサブフォルダーに伝達されていることを2回（および3回）確認しました。

グーグル博士のアドバイスで、私は設定ファイルに次の設定も追加しました。

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

define('WP_TEMP_DIR', ABSPATH . 'wp-content/');
define('FS_METHOD', 'direct');

構成オプションまたは設定がありませんか？WordPressは小さな子猫やアルジェリアのデグーの犠牲を必要としますか？

4

2 に答える 2

9

IIS7のインストールに関するPHPマニュアルから（強調は私のものです）：

なりすましとファイル システム アクセス

IIS を使用する場合は、PHP で FastCGI 偽装を有効にすることをお勧めします。これは、php.ini ファイルの fastcgi.impersonate ディレクティブによって制御されます。偽装が有効になっている場合、PHP は、 IIS 認証によって決定されたユーザー アカウントに代わって、すべてのファイル システム操作を実行します。これにより、同じ PHP プロセスが異なる IIS Web サイトで共有されている場合でも、各 Web サイトで IIS 認証に異なるユーザー アカウントが使用されている限り、それらの Web サイトの PHP スクリプトは互いのファイルにアクセスできなくなります。

たとえば、IIS 7 の既定の構成では、組み込みのユーザー アカウント IUSR を既定の ID として使用する匿名認証が有効になっています。つまり、IIS が PHP スクリプトを実行するには、それらのスクリプトに対する IUSR アカウントの読み取りアクセス許可を付与する必要があります。PHP アプリケーションが特定のファイルに対して書き込み操作を実行する必要がある場合、またはファイルをいくつかのフォルダーに書き込む必要がある場合、IUSR アカウントにはそれらへの書き込み権限が必要です。

「FastCGI を介して PHP を偽装する必要がありますか?」で説明したように。ServerFault に関する質問です。匿名ユーザーにサーバーへの書き込みアクセス権を付与すると、セキュリティ上の懸念があります。たとえば、WebDAV モジュールも有効にしている場合、誰でもこのプロトコルを使用してディレクトリに書き込むことができます!

したがって、私の推奨事項は次のとおりです。

  1. すべてのサイトに固有のアプリケーション プールが割り当てられていることを確認してください。
  2. アプリケーション プールの [処理モデル]の下の[詳細設定]で、ビルトイン アカウントを として設定します。ApplicationPoolIdentity
  3. でphp.iniの偽装を無効にすると、 IIS で設定されたアプリケーション プール IDfastcgi.impersonate = 0で PHP が実行されます。
  4. 自動的に生成されたアプリケーション プール ユーザー アカウントを使用して、フォルダーに読み取り/書き込みアクセス許可を設定します(例: "IIS AppPool\MyAppPoolName")。

このようにして、すべての PHP スクリプトがシステム アカウントで実行され、サイトのアプリケーション プールに関連付けられ (他のサイトから隔離され)、なりすましによって誤ってパブリック アクセスが取得されることがなくなります。

于 2012-06-28T13:53:39.570 に答える
2

間違っている場合は訂正してください。ただし、次の構成でも同じ利点が得られ、PHP の望ましい設定である fastcgi.impersonate=1 も尊重されると思います。

手順 1、2、4 は同じですが、手順 3 が異なります。

  1. 各サイトに独自のアプリケーション プールがあることを確認します (上記と同じ)。
  2. [詳細設定] > [処理モデル] > [アプリケーション プール ID] (上記と同じ) の下
  3. IIS > 認証 > 匿名認証 > アプリケーション プール ID (IUSR ではない)
  4. IIS AppPool\MyAppPoolName を使用して読み取り/書き込みアクセス許可を設定します (上記と同じ)。

Webroot への IUSR または IIS_IUSRS アクセスは許可しません。すべてのアクセス許可は IIS AppPool\MyAppPoolName に割り当てられます

于 2013-04-19T16:18:55.117 に答える