解决IIS7上WordPress的权限问题

我在通过WPI安装的Win2k8/IIS7上运行WordPress（使用httpcache、fastCgi和UrlRewriter 2.0）。一切似乎都很正常（上传、通过Live Writer发布、评论、插件、漂亮的URL）

我正在尝试将WordPress更新为最新版本，但出现如下错误：

下载失败。文件流的目标目录不存在 存在或不可写

这与我尝试下载主题或更新插件时遇到的错误相同

事件日志中没有错误，WordPress并没有告诉我它正在查找哪个目录，它认为它正在使用哪个用户，或者它缺少什么权限

我已双重（和三重）检查IIS应用程序池用户是否已显式设置，目录是否具有该用户的修改权限，最后检查这些权限是否已向下分配到子文件夹

在Google博士的建议下，我还向配置文件添加了以下设置：

/** 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是否需要牺牲一只小猫和/或一只阿尔及利亚德古猫？

（强调矿）：

模拟和文件系统访问

建议在使用时在PHP中启用FastCGI模拟 IIS这由中的fastcgi.impersonate指令控制 php.ini文件。启用模拟后，PHP将执行所有 代表已删除的用户帐户执行的文件系统操作 由IIS身份验证确定。这确保即使相同 PHP进程在不同的IIS网站、PHP脚本之间共享 在这些网站中，将无法访问彼此的文件 只要在上使用不同的用户帐户进行IIS身份验证 每个网站

例如，IIS 7在其默认配置中具有匿名性 已启用身份验证，内置用户帐户IUSR用作身份验证 默认标识这意味着为了让IIS执行PHP 脚本时，必须授予IUSR帐户对的读取权限 这些脚本。如果PHP应用程序需要在 某些文件或将文件写入某些文件夹，然后使用IUSR帐户 应该有书面许可

如中所述，如果您授予服务器上的匿名用户写访问权限，则存在安全问题。例如，如果您还启用了WebDAV模块，任何人都可以使用此协议写入您的目录

因此，我的建议是：

确保所有站点都分配了自己的唯一应用程序池

在应用程序池的处理模型下的高级设置中，将内置帐户设置为

ApplicationPoolIdentity

使用

fastcgi.impersonate=0禁用php.ini中的模拟，以便php在IIS中设置的应用程序池标识下运行

使用设置文件夹的读/写权限（例如“IIS AppPool\MyAppPoolName”）

通过这种方式，确保所有PHP脚本在系统帐户下运行，并与站点的应用程序池绑定（将其与其他站点隔离），并且不会意外地通过模拟获得太多的公共访问。

来自（emphasis mine）：

模拟和文件系统访问

建议在使用时在PHP中启用FastCGI模拟 IIS这由中的fastcgi.impersonate指令控制 php.ini文件。启用模拟后，PHP将执行所有 代表已删除的用户帐户执行的文件系统操作 由IIS身份验证确定。这确保即使相同 PHP进程在不同的IIS网站、PHP脚本之间共享 在这些网站中，将无法访问彼此的文件 只要在上使用不同的用户帐户进行IIS身份验证 每个网站

例如，IIS 7在其默认配置中具有匿名性 已启用身份验证，内置用户帐户IUSR用作身份验证 默认标识这意味着为了让IIS执行PHP 脚本时，必须授予IUSR帐户对的读取权限 这些脚本。如果PHP应用程序需要在 某些文件或将文件写入某些文件夹，然后使用IUSR帐户 应该有书面许可

如中所述，如果要授予匿名用户在服务器上的写访问权限，则存在安全问题。例如，如果您还启用了WebDAV模块，任何人都可以使用此协议写入您的目录

因此，我的建议是：

确保所有站点都分配了自己的唯一应用程序池

在应用程序池的处理模型下的高级设置中，将内置帐户设置为

ApplicationPoolIdentity

使用

fastcgi.impersonate=0禁用php.ini中的模拟，以便php在IIS中设置的应用程序池标识下运行

使用设置文件夹的读/写权限（例如“IIS AppPool\MyAppPoolName”）

---

这样，所有PHP脚本都可以确保在系统帐户下运行，绑定到站点的应用程序池（将其与其他站点隔离），并且不会意外地通过模拟获得太多的公共访问。

如果我错了，请纠正我的错误，但我相信以下配置提供了相同的好处，并且还支持PHP所需的fastcgi.impersonate=1设置

步骤1、2和4相同-步骤3不同

确保每个站点都有自己的应用程序池（同上）

在“高级设置>处理模型>应用程序池标识”下（同上）

IIS>身份验证>匿名身份验证>应用程序池标识（非IUSR）

使用IIS设置读/写权限