Сделайте Аутентификацию HTTP по HTTPS с перезаписью URL

Я пытаюсь защитить ~/public_html/dev каталог с помощью http основного автора, но заставить это защитить я хочу выполнить его по ssl.

Средний раздел ниже .htaccess файл переключается на https, если запрос URI начинается /dev и работы.

Последний раздел файла работает также, но не работает правильно с перенаправлением https.

Я в основном хочу смочь ввести http://www.example.com/dev/some_sub_dir/ и будьте перенаправлены к https://www.example.com/dev/some_sub_dir/ и запрошенный http подлинное имя пользователя и пароль.

То, что в настоящее время происходит, - то, если я перехожу в http://www.example.com/dev/some_sub_dir/ Мне предлагают имя пользователя и пароль по порту 80, и затем сразу будьте предложены снова по порту 443. Таким образом, мои учетные данные отправляются дважды, однажды в ясном, и когда-то шифруются. Создание целого https URL переписать немного бессмысленное.

Причина того, чтобы сделать это состоит в том так, чтобы я не мог случайно отправить своего пользователя/передачу по http; https всегда привыкнет к доступу /dev каталог.

.htaccess находится в ~/public_html/dev каталог.

# Rewrite Rules for example.com
RewriteEngine On
RewriteBase /

# force /dev over https
RewriteCond %{HTTPS} !on
RewriteCond %{REQUEST_URI} ^/dev
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

# do auth
AuthType Basic
AuthName "dev"
AuthUserFile /home/matt/public_html/dev/.htpasswd
Require valid-user
7
задан Matthew 6 July 2013 в 14:10
поделиться

3 ответа

Защита содержимого с помощью базовой проверки подлинности никогда не будет надежно работать через HTTP.

После того, как пользователь ввел свое имя пользователя и пароль, он отправляется в незашифрованном виде при каждом просмотре страницы на этот сайт, а не просто отправляется время, когда пользователю предлагается.

Вы должны рассматривать запросы через HTTP как неаутентифицированные и делать все входящие в систему данные через HTTPS.

Многие веб-сайты использовали HTTPS для входа в систему, используя формы и файлы cookie, а не базовую аутентификацию, а затем переходили на HTTP. Это означает, что их cookie «вы вошли в систему» ​​отправляются в незашифрованном виде. Все ценные цели были взломаны из-за этого, и теперь Gmail переходит на полный HTTPS, и другие последуют за ним.

У вас нет тех же проблем с масштабированием, которые были у других, которые удерживали их от более дорогостоящего в вычислительном отношении HTTPS. Если ваша домашняя страница поддерживает доступ по протоколу HTTPS, используйте его повсюду.

2
ответ дан 6 December 2019 в 08:14
поделиться

Можно ли поместить раздел аутентификации в тег или с помощью тега протокол в качестве термина?

0
ответ дан 6 December 2019 в 08:14
поделиться

Я столкнулся с той же проблемой и, наконец, нашел уродливое решение, но оно работает. Поместите правило перезаписи в директиву Directory в httpd.conf или в один из ваших файлов conf.d (т. Е. В конфигурации «Основного» сервера). Затем поместите строки Auth * и Require в директиву Directory внутри контейнера в ssl.conf (или там, где определен ваш SSL VirtualHost).

Для меня это означает создание файла /etc/httpd/conf.d/test.conf с:

<Directory "/var/www/html/test">
        #
        # force HTTPS
        #
        RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</Directory>

... и затем добавление следующего внутри / etc / httpd /conf.d/ssl.conf чуть выше тега :

<Directory "/var/www/html/test">
        #
        # require authentication
        #
        AuthType Basic
        AuthName "Please Log In"
        AuthUserFile /var/www/auth/passwords
        Require valid-user
</Directory>

Это заставляет Apache применять RewriteRule ко всем запросам, а требования аутентификации только к запросам в 443 VirtualHost.

4
ответ дан 6 December 2019 в 08:14
поделиться
Другие вопросы по тегам:

Похожие вопросы: