Apache Reverse Proxy Отправка браузера для Backend непосредственно Вместо

Question

(UPDATE в нижней части для основного вопроса, ниже может быть лишних деталей)

У меня интересная проблема с Apache не перепутать проксирование, как ожидалось.

В принципе, то, что происходит, когда я нажимаю ссылку на моем сайте, который идет к относительному пути /app1, я ожидаю ему URL, чтобы быть external.company.ca/app1 с содержанием наступающего из internal.company.ca/some_app. Вместо этого браузер переходит непосредственно к internal.company.ca/some_app.

№ 302 или что-то еще, прямо здесь. Это странно для меня, так как internal.company.ca не упоминается нигде в конфигурации, кроме конфигурации обратного прокси, поэтому я не знаю, как браузер вообще узнает о домене.

Вот захват Fiddler с точки зрения клиента (браузера), показывающий поведение сразу после того, как я нажму ссылку, которая идет на /app1 (вам придется доверять мне, что зеленые имена - external.company.ca, а черные имена - internal.company.com и путь /some_app/blahblah):

Все, что происходит после того, как эта точка загрузки страницы с internal.company.com. Разумеется, это не будет работать вообще.

Ниже приводится (усеченный) версии наших файлов конфигурации Apache для рассмотрения:

<VirtualHost *:80> 
    # rewrite rules to 443 
</VirtualHost> 

<VirtualHost *:443> 
    ServerName external.company.ca 
    ServerAlias external.company.com 

    # Logging rules......... 

    SSLEngine on 
    SSLProxyEngine on 
    SSLProxyVerify none 

    # Most of this is off for testing purposes, adding in case it matters 

    SSLProxyCheckPeerCN off 
    SSLProxyCheckPeerName off 
    SSLProxyCheckPeerExpire off 

    # more SSL stuff.... Now on to the interesting part 

    ProxyPreserveHost On 
    ProxyPass /app1 https://internal.company.com/some_app 
    ProxyPassReverse /app1 https://internal.company.com/some_app 
</VirtualHost> 

В какой-то момент я подумал, что, возможно, печенье кидали вещи, так как они были в разных доменах (.ca спереди, .com сзади), но я считаю, что если обратное проксирование работает правильно, браузер не будет более мудрее. Кто-нибудь видит что-то не так с этим?

UPDATE

Я нашел виновника:

<script type="text/javascript">window.location.assign('https://internal.company.com/app1/login?redirectUrl=' + encodeURIComponent(window.location.pathname + window.location.hash));</script>

Проблема заключается в том, как я могу переписать этот абсолютный URL с помощью Apache? Я знаю, mod_proxy_html изменяет атрибуты элемента (например, href в элементе a), но может ли он переписать произвольные данные в самом элементе?

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

Answer 1

Я придумал несколько неприятную обходным:

ProxyHTMLEnable On 
ProxyHTMLExtended On 
ProxyHTMLLinks script src 
ProxyHTMLURLMap https://internal.company.com 

Проблема является использование абсолютного URL, по всему HTML (и JavaScript) наступающем из приложения поставщика. Поиск и удаление домена решает проблему (но невероятно медленно).

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

Answer 2

Возможно, более безопасным решением будет использование mod_substitute. Вы также можете рассмотреть ProxyHTMLExtended, но он может быть довольно жестоким в его заменах, изредка нарушая JavaScript здесь и там.

Редактировать: Просто заметили, что вы используете ProxyHTMLExtended. Виноват. Как вы подчеркнули, это довольно жестокое и опасное решение проблемы.