странная ошибка 401 появляется для некоторых URL при использовании .htaccess для перенаправления http на https

Question

ОК, вот 7-й день неудачной попытки найти ответ, почему появляется ошибка 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, перенаправлений нет.

Это понятно, и проблема ниже.

Я хочу, чтобы / admin каталог был защищен паролем.Моя панель управления хостингом позволяет защищать каталоги без ручного создания .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?

PSCreating .htaccess и .htpasswd вручную (не из панели управления хостингом) для папки / администрирования вызывает те же 401ошибка в случае, если не https, но http был введен.

И проблема возникает с URL-адресами только в / Administration Directory.

Спасибо.

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]

Я чувствую себя немного плохо из-за того, что пишу это, так как, на мой взгляд, это выглядит как хакерство.

EDIT Кажется, 2-й вариант исправил проблему. Итак, вот объяснение, почему это работает.

Модуль аутентификации выполняется перед модулем перезаписи. Поскольку имя пользователя и пароль не отправляются при первом запросе страницы, модуль аутентификации внутренне «перезаписывает» URL-адрес запроса на URL-адрес страницы 401. После этого приходит mod_rewrite и% {THE_REQUEST} теперь содержит 401.shtml вместо исходного URL. Таким образом, полученное перенаправление содержит 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/

- EDIT

В конце концов я обнаружил, что основной причиной проблемы была ModSecurity, помечающая мои данные POST (теги script и iframe вызывают проблемы).Он попытался бы вернуть 401/403, но не смог найти документ об ошибке по умолчанию, потому что ModSecurity сделал мой htaccess бесполезным.

Использование ErrorDocument 401 «Unauthorized» обошло проблему отсутствующего документа об ошибках, но ничего не решилоосновная причина.

Для этого я в конечном итоге использовал javascript, чтобы добавить 'salt' к чему-либо, что не было ни пробелом, ни символом слова ...

  $("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!

Примечания Regex:
Я подумал, что стоит упомянуть, что здесь происходит ...

(?: foobar) + = соответствовать первой половинесолить один или несколько раз, но не хранить это как сопоставленную группу;

(.) = сопоставить с любым символом и сохранить это как первую и единственную группу (доступную через $ 1);

(?: соль) + = соответствует второй половине соли один или несколькораз, но не сохраняйте это как совпавшую группу.

Важно сопоставлять соль несколько раз на символ, потому что если вы нажмете «Отправить», а затем нажмете кнопку «Назад», вы вернетесь к форме свся соль все еще там.Нажмите еще раз и добавьте больше соли.Это может происходить снова и снова, пока вы не получите что-то вроде: foobarfoobarfoobarfoobar> saltaltsaltsalt