Рейтинг:0

размещение двух приложений в одном домене с использованием apache, одно с базовой аутентификацией

флаг jp

у меня проблемы с настройкой апач.

Приложения:

  • приложение 1 — SPA (интерфейс), работающее в докере. Доступно локально через http://локальный: 91

  • приложение 2 — WebAPI (серверная служба), работающее в докере. Доступно локально через http://локальный: 90

Я хотел бы сделать оба приложения доступными в одном домене через HTTPS, используя апач:

  • приложение 1: https://мой.домен.com <- должен быть защищен базовой аутентификацией.
  • приложение 2: https://мой.домен.com/api

Я думал, что эта настройка работает, когда я использовал простой HTTP для доступа к ресурсам, но как только я переключился на HTTPS (самоподписанный с letsencrypt) - вроде все перестало работать.

вот последняя конфигурация

<VirtualHost *:80>
    ServerName my.domain.com
    ServerAlias www.my.domain.com
    
    TraceEnable off

    RewriteEngine on
    RewriteCond %{SERVER_NAME} =www.my.domain.com [OR]
    RewriteCond %{SERVER_NAME} =my.domain.com
    RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
    
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerName my.domain.com
    ServerAlias www.my.domain.com

    TraceEnable off
    ProxyRequests Off
    ProxyPreserveHost On
    
    <Proxy *>
        Order deny,allow
        #Allow from all
        Allow from 127.0.0.1
    </Proxy>
    
    Timeout 2400
    ProxyTimeout 2400
    ProxyBadHeader Ignore 

    <Location />
        AuthType Basic
        AuthName "Restricted Content"
        AuthUserFile /etc/apache2/.htpasswd
        Require valid-user
        
        ProxyPass        http://localhost:91/ Keepalive=On
        ProxyPassReverse http://localhost:91/
    </Location>
    
    <Location /api>
        ProxyPass        http://localhost:90/
        ProxyPassReverse http://localhost:90/
    </Location>
    
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    Include /etc/letsencrypt/options-ssl-apache.conf
    SSLCertificateFile /etc/letsencrypt/live/my.domain.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/my.domain.com/privkey.pem
</VirtualHost>
</IfModule>

Последняя и актуальная проблема:

Всякий раз, когда я пытаюсь получить доступ к конечной точке https://my.domain.com/api/Аутентификация/Вход - пользователю предлагается страница входа. Это должно быть действительно только для URL-адресов, отличных от API.

Другими словами - <Location /api> директива, кажется, игнорируется.Я пробовал перетасовывать директивы местоположения, а также десятки других решений, и ни одно из них не работает. Я также пробовал более явную директиву, например <LocationMatch /(api).*> это тоже не сработало.

Что-то не так с правилами сопоставления местоположений?

Рейтинг:3
флаг in

<Location /api> не игнорируется, вы просто не настроили для него аутентификацию, поэтому применяется конфигурация более высокого уровня.

Запрещать Тип авторизации для местоположения:

<Location /api>
    AuthType None
    Require all granted
    ProxyPass        http://localhost:90/
    ProxyPassReverse http://localhost:90/
</Location>
djdomi avatar
флаг za
правда, это наоборот, способ исправить это, другой саб-дом тоже сработает ;)
флаг jp
@ Джеральд Отлично! Один дополнительный вопрос. Когда я пытаюсь перейти к `https://my.domain.com/manifest.json`, файл будет открыт, как если бы это была веб-страница (т.е. ресурс не будет найден). С другой стороны, если я попытаюсь получить к нему доступ напрямую по локальному IP-адресу ПК: `http://192.168.0.110:91/manifest.json`, я наткнусь на реальный файл, размещенный в SPA. То же самое касается любого файла CSS и JS. Несмотря на то, что ни один из файлов не доступен из внешней сети, веб-страница по-прежнему загружается правильно. Есть ли хорошее объяснение такому поведению? Можно ли сделать все файлы доступными как есть?
флаг in
Это должен быть новый вопрос, но можно предположить, что внутренний сервер использует разные корни документов или виртуальные хосты, если доступ к ним осуществляется через локальный хост и 192.168.0.110.
флаг jp
Еще одна вещь, которую я заметил при доступе к `http://192.168.0.110:91/`, - это ошибка 403 для зарегистрированного запроса типа `OPTIONS`, что делает веб-сайт непригодным для использования (CORS не будет работать). После установки «loglevel» и дальнейшего изучения журналов «apache» я обнаружил следующую строку «AH01797: клиент запрещен конфигурацией сервера: прокси: http://localhost: 90/Auth/Login, referer: ...». Мне удалось исправить это, добавив «Разрешить от всех» вскоре после «Требовать все предоставлено». Не уверен, что это правильно, но это решило проблему.
флаг jp
И еще есть одна нерешенная проблема - при доступе к сайту по доменному имени загружается "кешированная версия" сайта. т.е. даже если была развернута более новая версия SPA, браузер, похоже, не так стремится обновить содержимое. Мне еще предстоит во всем этом разобраться, но проблема, похоже, также связана с конфигурацией apache, поскольку такой проблемы нет, когда доступ к сайту осуществляется по локальному IP-адресу. Несмотря на это, я думаю, что позже открою новый вопрос для этого сценария после более подробного изучения этой проблемы.

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.