为什么使CURLOPT_FOLLOWLOCATION与open_basedir不兼容？ [英] Why was CURLOPT_FOLLOWLOCATION made incompatible with open_basedir?

问题描述

当服务器管理员设置 open_basedir 时，PHP的cURL库不允许进行以下HTTP重定向。
这在SO上产生了问题，例如 curl跟随位置错误，其中有很多重复项，大多数答案是切换到允许关闭 open_basedir 的托管服务提供商或抽象反转试图（以不同的质量级别）在PHP中重新实现cURL的HTTP重定向逻辑。

我只是想知道为什么PHP开发人员首先选择使它们互斥。
服务器管理员设置 open_basedir 时，PHP拒绝遵循从一个HTTP或HTTPS URI到另一个HTTP或HTTPS URI重定向的策略有何安全目的？ / p>

解决方案

最初是因为 libcurl 不会忽略<$ c而实现的$ c>位置：file：// 重定向。由于 curl 也允许本地文件访问，因此这将破坏baseir的约束。

这种设计的不兼容性被放松了在最新版本中，btw：

• https://bugs.php.net/bug.php?id=65646


• https://github.com/php/php-src/commit/fba290c061027c24e4c8effdba37addd3430c3d4

ul>


PHP's cURL library doesn't allow following HTTP redirects when the server administrator has set open_basedir. This has produced questions on SO like curl follow location error with a lot of duplicates, and most answers are either "switch to a hosting provider that allows turning off open_basedir" or abstraction inversions that attempt (with varying levels of quality) to reimplement cURL's HTTP redirect logic in PHP.

I just wonder why the PHP developers chose to make them mutually exclusive in the first place. What security purpose does PHP's policy of refusing to follow redirects from one HTTP or HTTPS URI to another HTTP or HTTPS URI when the server administrator has set open_basedir serve?

解决方案

It was originally implemented because libcurl didn't ignore Location: file:// redirects. Since curl also allows local file access this would have subverted the basedir constraints.

This designed "incompatibility" was loosened in more recent versions, btw:

• https://bugs.php.net/bug.php?id=65646
• https://github.com/php/php-src/commit/fba290c061027c24e4c8effdba37addd3430c3d4

这篇关于为什么使CURLOPT_FOLLOWLOCATION与open_basedir不兼容？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！