PHP：CURLOPT_FOLLOWLOCATION 和 open_basedir 可以一起使用吗？答案

【问题标题】：PHP: Can CURLOPT_FOLLOWLOCATION and open_basedir be used together?PHP：CURLOPT_FOLLOWLOCATION 和 open_basedir 可以一起使用吗？
【发布时间】：2013-11-01 15:00:10
【问题描述】：

我很困惑为什么这两个东西是或看起来是相互排斥的，并且想知道是否有办法在 PHP-5.4 上同时使用这两者。尝试设置此选项，我收到以下错误：

curl_setopt(): CURLOPT_FOLLOWLOCATION cannot be activated when an open_basedir is set

我正在使用需要设置 CURLOPT_FOLLOWLOCATION 的 MailChimp API 库。重定向可能会发生，应该遵循，这就是互联网的工作方式。

我也在域上使用 open_basedir。我想围住网站能够访问的目录。这只是一个安全的东西，以及安全带和其他安全措施。

那么，有什么方法可以同时使用它们吗？我希望 CURL 遵循重定向，但也保持 PHP 脚本对已定义目录的本地文件访问。我见过的唯一一种攻击这个问题的方法是在重定向之后模拟 CURL，但这看起来很笨拙，那么 CURL 已经被设计为这样做了。

编辑：

如果不清楚，这是我正在使用的包中抛出错误的行：

curl_setopt($this->ch, CURLOPT_FOLLOWLOCATION, true);

IMO PHP 保护过度，它应该允许我这样做。那么有没有办法 - 无需破解/分叉这个包 - 告诉 PHP，“看，我知道我在这里做什么”？

我已将其作为包开发人员的问题提出，但迄今为止尚未得到回复。如果包支持传输层的注入，那么我可以通过使用 PHP 的 curl 函数的替代方法来解决它。

【问题讨论】：

我发现的大多数线程都只是说“关闭 open_basedir”。好吧，不，我不想那样做。如果最坏的情况发生并且有人进入网站后端，这是我们为降低域之间传播损害的风险而采取的措施之一。
也许问题是 curl 通过在 PHP 控制之外的 curl 库中操作绕过了 PHP 中的 open_basedir 设置，而 PHP 只是试图通过阻止我犯错来提供帮助。但是，我相信发送 curl 的 URL，所以这应该是我的决定。我不能告诉 PHP 重定向可以信任，所以“退出”并让我这样做吗？ ;-)
这个问题似乎是说我不得不破解外部包，这是我想尝试避免的事情：stackoverflow.com/questions/3890631/… 其他博客也提供示例代码来跟踪来自外部的重定向卷曲调用。

标签： php curl mailchimp open-basedir

【解决方案1】：

我将撤回这个问题，因为它似乎使人们感到困惑（编辑：抱歉，听起来居高临下，这不是故意的；我没有正确解释问题，以及我和其他人施加的限制任何建议的解决方案）。

答案似乎是，“不，你不能那样做”。 PHP curl (curl_setopt) 上的 CURLOPT_FOLLOWLOCATION 选项和 php.ini 中的 open_basedir 选项基本上是不兼容的，没有任何编程方式可以让它们一起工作。

我将分叉第三方包，用代码中的手动重定向解决方法替换 CURLOPT_FOLLOWLOCATION 选项，在 SO 上有一些示例。我也会继续推动包开发人员修复这个错误。

感谢您花时间回复。

编辑：这里真正的问题是 PHP 由于十年前提出的错误而强加的钝器解决方案：

https://bugs.php.net/bug.php?id=30609

问题出在 curl 库中 - 如果 PHP 告诉它不要潜入本地文件系统，则不应允许它潜入本地文件系统（也许除了 open_basedir 目录）。由于 curl 和 PHP 整整十年都没有一起解决这个问题，所以是时候停止使用 curl 了——它不适合目的。国际海事组织。

【讨论】：

好的，但在这种情况下，您不能在运行时更改open_basedir，并且仅在您执行此 cUrl 调用时更改？
如果可以的话，那肯定会成功。如果你想把它作为答案，我会撤销我的。
答案已编辑。我真的很确定我已经在我的一个 cmets 中提到了这一点，但情况似乎并非如此。不管怎样，最重要的是：问题解决了吗？
我一直在研究这个并尝试了各种各样的东西，我也得出了同样的结论，由于某种逃避逻辑的原因，你不能同时拥有两者。真可惜，因为open_basedir 实际上是一种有用的安全措施。

【解决方案2】：

Curl 是独立的库，不应直接受 PHP 的 open_basedir 影响。你怎么称呼这个？能否提供一些代码和更详细的解释？

“Curl 目标应用程序具有限制性open_basedir”

和

“Curl 源应用具有限制性open_basedir”

是两个不同的东西。 PHP 的open_basedir 应该只影响传入的请求。

编辑： PHP 5.3.0 之后 open_basedir 可以更改运行时。它是listed in the manual。这个也解释了in the general section，但是解释非常非常模糊：

Name:         Default:  Changeable:     Changelog:
open_basedir    NULL    PHP_INI_ALL     PHP_INI_SYSTEM in PHP < 5.3.0

如果您有权访问或控制源，只需在需要时调用它。干杯!

【讨论】：

鉴于此，我可以看到 PHP 所做背后的逻辑：如果设置了 open_basedir，则 curl 指向的外部站点能够重定向到内部路径（使用文件： //whatever) 在 PHP 中被禁用。但是，当我知道并信任我的 PHP curl 从中请求数据的站点时，“保护”就会成为障碍。 PHP中有没有办法解决它？我意识到除了 curl 之外还有其他方法，但我正在引入一个恰好使用它并需要重定向支持的外部库。
是的，curl 是一个独立的库，不受 PHP 设置的影响。但是，如果尝试将某些选项传递给 curl，PHP 会引发错误，考虑到某些 PHP 设置，很可能是为了让我远离潜在的麻烦。
@Jason 你能再解释一下吗？我无法解决你的问题？是不是当您调用 appDestination 时，该应用程序会尝试进行内部重定向？那么由于open_basedir 设置，该重定向会变得“黑洞”吗？如果是这样，您是否可以控制该应用的来源？
我也将此作为第三方软件包的问题提出。他们不应该需要这个 curl 选项并自己解决它，或者使用 DI 进行传输，以便可以将其固定在包装之外。这在 PHP5.3 中是一个警告，但在 PHP5.4 中似乎变成了一个致命错误。无论如何，重定向功能都是需要的。
文档提到 open_basedir 可以在运行时tightened，即限制性更强，但不能关闭它，除非我找错地方了.我可能只需要为这个虚拟主机关闭它 - 至少不需要为整个服务器关闭它。