使用 .htaccess 将 http 重定向到 https 时，某些 url 会出现奇怪的 401 错误

Question

好的，这是第七天尝试寻找 401 错误出现原因的失败尝试...

现在， 根文件夹中的 .htaccess 仅包含 3 个字符串（已简化），并且项目中不再有 .htaccess 文件：

RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

因此，它将所有请求重定向为 https。它适用于任何 url，甚至适用于 /administration 目录。

因此，

http://mydomain.com

。

https://mydomain.com

如果输入了 https://mydomain.com，则不会发生重定向

http://mydomain.com/administration/index.php

变为

https://mydomain.com/administration/index.php

如果输入了https://mydomain.com/administration/index.php，则没有重定向。

这很清楚，问题在下面。

我希望 /administration 目录受到密码保护。我的共享主机控制面板允许保护目录，而无需手动创建 .htaccess 和 .htpasswd（您选择要保护的目录，创建用户名和密码，然后自动创建 .htaccess 和 .htpasswd）。因此，.htaccess 出现在 /administration 文件夹中。 .htpasswd 出现在其他地方，.htpasswd 的路径是正确的，并且一切看起来都是正确的（其工作方式与手动创建它相同）。因此，项目中有 2 个 .htaccess 文件，一个位于根目录，一个位于 /administration 目录（其中 .htpasswd 位于目录 .htaccess 知道它在哪里）。

创建密码后， 结果是：

您输入：

https://mydomain.com/administration/index.php

然后它要求输入密码。 如果输入正确的话 显示 https://mydomain.com/administration/index.php。 结果：完美。

但是，如果你输入 http://mydomain.com/administration/index.php（是的，http，不带 S） 然后不是重定向到相同的 https 页面， 它以未知原因重定向

https://mydomain.com/401.shtml (starts with httpS)

，甚至不询问密码。 为什么？

我已经就这个问题联系了客户支持，他们确定问题出在 .htaccess 文件中，并且他们没有修复 .htaccess 文件（很明显，他们没有，我也没有）不介意）。

为什么会发生这种情况？ 我是否忘记在 .htaccess 文件中放置一些标志或一些选项来更改默认设置？

如果输入的不是 https，而是 http，则为文件夹 /administration 手动创建 .htaccess 和 .htpasswd（不是从托管控制面板）会导致相同的 401 错误。

仅当 URL 指向 /administration 目录时才会出现此问题。

谢谢。

Answer 1

尝试使用这个代替。不是 L 和 R 标志。

RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

还要先清除浏览器缓存，以删除旧的不正确的重定向。

如果这不起作用，请尝试使用这个。

RewriteCond %{HTTPS} !on
RewriteCond %{THE_REQUEST} ^(GET|HEAD)\ ([^\ ]+)
RewriteRule ^ https://%{HTTP_HOST}%2 [L,R=301]

我觉得写它有点不好，因为在我看来这有点黑客。

编辑
看来第二个选项解决了问题。所以这里是关于它为什么起作用的解释。

认证模块在重写模块之前执行。由于首次请求页面时未发送用户名和密码，因此身份验证模块在内部将请求 url“重写”为 401 页面的 url。此 mod_rewrite 出现后，%{THE_REQUEST} 现在包含 401.shtml 而不是原始网址。因此，生成的重定向包含 401.shtml，而不是您想要的 url。

要获取原始（不是“重写”）的 url，您需要从 %{THE_REQUEST} 中提取它。 THE_REQUEST 的格式为 [requestmethod] [url] HTTP[versionnumber]。 RewriteCond 仅提取中间部分 ([url])。

为了完整起见，我将 [L,R=301] 标志添加到第二个解决方案中。

Answer 2

我想我找到了更好的解决方案！

只需将其添加到位于以下位置的 .htaccess

ErrorDocument 401 "Unauthorized"

解决方案：

http://forum.kohanaframework.org/discussion/8934/solved-for-reall-this-time-p-htaccess-folder-password-protection/

- 编辑

我最终发现该问题的根本原因是 ModSecurity 标记了我的 POST 数据（脚本和 iframe 标记导致问题）。它会尝试返回 401/403，但找不到默认错误文档，因为 ModSecurity 让我的 htaccess 变得混乱。

使用ErrorDocument 401“Unauthorized”绕过了丢失错误文档的问题，但没有解决根本原因。

为此，我最终使用 javascript 将“盐”添加到既不是空格也不是单词字符的任何内容...

  $("form").submit(function(event) {
    $("textarea,[type=text]").each(function() {
      $(this).val($(this).val().replace(/([^\s\w])/g, "foobar$1salt"));
    });
  });

然后 PHP 再次去除盐...

function stripSalt($value) {
  if (is_array($value)) $value = array_map('stripSalt', $value);
  else $value = preg_replace("/(?:foobar)+(.)(?:salt)+/", "$1", $value);

  return $value;
}
$_POST = stripSalt($_POST);

非常、非常、非常重要的注意事项：
不要使用“foobar$1salt”，否则这篇文章只是向黑客展示了如何绕过您的 ModSecurity！

正则表达式注释：
我认为可能值得一提这里发生的事情...

(?:foobar)+ = 匹配盐的前半部分一次或多次，但不要将其存储为匹配组；

(.) = 匹配任何字符并将其存储为第一个也是唯一的组（可通过 $1 访问）；

(?:salt)+ = 匹配盐的后半部分一次或多次，但不要将其存储为匹配组。

每个字符多次匹配盐很重要，因为如果您点击提交然后使用后退按钮，您将返回到表单，所有盐仍然在那里。再次点击提交，就会添加更多的盐。这种情况可能会一次又一次地发生，直到你最终得到类似的结果：
foob​​arfoobarfoobarfoobar>盐盐盐盐盐

Answer 3

我对上述解决方案并不满意，因此我提出了另一种解决方案：

在现代 Web 服务器配置中，我们应该将所有流量重定向到 HTTPS，这样用户就无法在没有 HTTPS 的情况下访问任何内容。用户使用 HTTPS 浏览我们的内容后，我们可以使用身份验证。考虑到这一点，我们可以将身份验证指令包装在 If 指令中：

<If "%{HTTPS} == 'on'">
  AuthType Basic
  ...
</If>

您可以根据需要保留并使用 Rewrite 指令。

使用此解决方案：

• 您不得按照 Hoogs 的建议更改 ErrorDocument
• 您不得按照 Gerben 的建议以黑客方式从 THE_REQUEST 中提取路径

Answer 4

这种情况是，在没有框在您面前的情况下在 Apache 上进行故障排除有点棘手，但我认为发生的是您的重写指令在路径解析后正在处理，并且是有密码要求的路径解析。

回顾一下，Apache 中解析 URL 的方式是请求传入并从一个模块传递到另一个模块，有点像桶队。每个模块都做自己的事情......有些模块进行内容协商，有些模块将 URL 转换为文件路径，有些检查身份验证，其中之一是 mod_rewrite ...

您在配置中看到这一点的地方实际上是两者都有Location 指令和 Directory 指令在大多数方面看起来相同，但它们是不同的，因为 Locations 讨论 URL，而 Directory 讨论文件系统路径。

无论如何，我的猜测是，Apache 在发现需要重定向到 HTTPS 之前，发现它需要密码才能访问该内容。 （mod_rewrite 是一种疯狂的模块，它可以以令人惊讶的方式搞乱各种事情......它可以进行路径转换、一点点重写、发出子请求和一堆其他疯狂的事情）。

我能想到的解决这个问题的方法很少。

1. 更改 http 站点的 vhosts 容器中的目录根目录，以便它找不到密码文件（这将是我的方法）
2. 更改模块加载顺序，以便 mod_rewrite 在链中较早发生（可能会产生意外后果）
3. 使用 < code>setenvif

最后一个需要更多解释。还记得我跟你说过的水桶大队吗？ Apache模块还可以设置环境变量，这些变量完全位于模块->模块->模块->链之外。如果站点不是 HTTPS，您也许可以设置一个环境变量。然后，无论您如何设置访问控制，都可以使用 SetEnvIf 指令来始终允许访问已设置的资源，但您必须确保您将遵守该重写规则。

正如我所说，我的选择是#1，但有时人们需要做一些疯狂的事情，而 Apache 会让你这么做。

如今，我对 https:// 网站的实际 SOP 是，我只是将所有端口 80 内容发送到一个根本无法提供任何内容的虚拟主机。然后我 mod_rewrite 所有内容都通过 https://... badda bing，baddaoom，没有 http，也没有复杂的安全风险。