Назад | Перейти на главную страницу

Может ли базовая аутентификация apache работать с настраиваемым портом SSL

Это для устаревшей системы, работающей под управлением Apache 2.2, и по разным причинам безопасный веб-сервер не может работать на порту 443 (этот порт используется чем-то другим). Итак, он настроен для работы на порту 8443, и у меня есть эта строка в конфигурации без SSL, которая перенаправляет все запросы на страницы администратора на безопасное соединение:

RewriteRule ^/admin(.*)$ https://%{SERVER_NAME}:8443/admin [R=302,L]

Это нормально работает - если вы попытаетесь перейти к:

http://server.com/admin

вы правильно перенаправлены на:

https://server.com:8443/admin

В этот момент появляется форма аутентификации для входа в систему с AuthType установлен в Digest. Кажется, это работает нормально, но при вводе действительного имени пользователя и пароля браузер перенаправляется на:

https://server.com/admin
^^^^^             ^

Обратите внимание на отсутствующий номер порта. Теперь, если вы начнете с ввода полного правильного адреса в браузере:

https://server.com:8443/admin

затем появляется та же форма аутентификации apache, но на этот раз после входа в систему номер порта сохраняется, и отображается страница администратора.

Итак, мой вопрос: могу ли я, не меняя номеров портов, перенаправить страницу без SSL на страницу SSL таким образом, чтобы сохранить номер порта после аутентификация? Я не смог найти ничего в документации Auth Digest о номерах портов, но предполагаю, что это как-то связано с исходным URI, полученным либо из запроса браузера, либо из правила перезаписи.

Обычная проверка подлинности может выполняться на любом порту. Обычная проверка подлинности также выполняет проверку подлинности для определенного ресурса и вообще не включает никаких перенаправлений: вместо этого она снова запрашивает тот же URL-адрес после диалогового окна пароля, но на этот раз с учетными данными внутри HTTP-запроса. Поскольку перенаправление не связано с базовой аутентификацией, это означает, что перенаправление, которое вы видите, не вызвано аутентификацией, а явно настроено где-то в вашей конфигурации.

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

Конфигурация без SSL:

<VirtualHost *:80>
    ServerName server.com
    RewriteEngine On

    RewriteRule ^/secret(.*)$ https://%{SERVER_NAME}:8443/secret [R=302,L]
    RewriteRule ^/public(.*)$ https://%{SERVER_NAME}:8443/public [R=302,L]
</VirtualHost>

SSL conf:

LoadModule ssl_module modules/mod_ssl.so
NameVirtualHost *:8443
Listen *:8443

<VirtualHost *:8443>
    ServerName server.com:8443
    UseCanonicalName On
    SSLEngine on

    # SSL cert/key
    SSLCertificateFile /path/to/cert.crt
    SSLCertificateChainFile /path/to/cert.chain.crt
    SSLCertificateKeyFile /path/to/cert.key

    DocumentRoot    "/var/www"

    <Directory "/var/www/public">
      DirectoryIndex index.html index.php
      Options -Indexes FollowSymlinks
      Order allow,deny
      Allow from all
    </Directory>

    <Directory "/var/www/secret">
      DirectoryIndex index.php index.html
      AuthName "Secret Pages"
      AuthType Digest
      AuthUserFile /etc/httpd/test-digests
      Require valid-user
      Options -Indexes FollowSymlinks
      AllowOverride None
      Order allow,deny
      Allow from localhost.localdomain
      Satisfy any
    </Directory>

</VirtualHost>

Обратите внимание ServerName строка в конфигурации SSL. Если я не поместите туда нестандартный порт, тогда дайджест-перенаправление будет использовать стандартный https-порт 443 после ввода имени пользователя / пароля, что приведет к поведению, которое я описал в исходном вопросе. Как только порт будет там, поведение будет таким, как требуется.

Таким образом, по крайней мере, из этого следует, что если SSL работает на нестандартном порту и использует дайджест-аутентификацию (или, я полагаю, базовую) apache-аутентификации, необходимо указать порт в конфигурации ServerName. Этого я не видел в документации.