Я разрабатываю веб-приложение, которому необходимо встраивать страницы из устаревшего веб-приложения в iframe, который необходимо распознать как одно и то же происхождение, чтобы страница могла взаимодействовать с содержимым iframe через javascript.
Поскольку я разрабатываю на localhost. Поэтому мне нужен способ проксирования устаревшего приложения, чтобы оно также отображалось на локальном хосте (или, по крайней мере, так же, как что-то, размещенное локально).
Чтобы немного усложнить ситуацию, из-за указа богов брандмауэра, на который я не могу повлиять, я не могу получить доступ к общедоступному устаревшему приложению (которое размещено в том же здании), в частности, из моей сети разработки, если я не использую ssh-туннель к некоторым произвольную точку выхода в общедоступном Интернете и настройте Chrome для доступа к домену устаревшего приложения через полученный локальный прокси-сервер socks. В производственной среде этой проблемы не будет, но пока мне нужно работать с тем, что у меня есть.
Это похоже на что-то решаемое с определенной локальной конфигурацией nginx, которая будет представлять как мое локально работающее веб-приложение, так и проксируемое устаревшее приложение как один и тот же хост, хотя я не уверен, как это будет называться.
Есть ли другие, возможно, более простые решения, которые мне следует рассмотреть?
Разобьем проблему на две задачи.
Поскольку администраторы брандмауэра на вашем рабочем месте решили, что не должно быть возможности получить доступ к устаревшему приложению непосредственно из сети разработки, вы решили использовать туннель SSH, чтобы обойти это.
Я бы не рекомендовал этот подход, но, поскольку вы сказали, что мы должны работать с тем, что у вас есть, это то, что мы должны будем сделать. Однако я бы исследовал, сможете ли вы подключиться к веб-серверу устаревшего приложения, используя внутренний IP-адрес, а не внешний. Очевидное отсутствие доступа может быть просто результатом отсутствия NAT-закрепление служба поддержки.
Но если вы просто не можете установить прямой TCP-сеанс с веб-сервером, можно использовать трюк SSH. Вместо использования «динамического» туннельного подхода, когда ваш SSH-клиент выдает себя за прокси-сервер SOCKS, вам следует использовать статический («локальный» порт) туннель. Что-то вроде localhost: 8081 -> [ssh tunnel] -> legacyapp.example.com:80.
Вам нужно что-то вроде «подкаталога», чтобы прикрепить устаревшее приложение. Что вы хотите использовать, так это функцию «обратного прокси», как описано на сайте Nginx.
Вам нужно также помнить об отправке правильного заголовка Host, если устаревшее приложение находится на виртуальном хосте. Включение чего-то вроде этого в свою конфигурацию должно быть близко к тому, что вы хотите:
location /legacyapp/ {
proxy_set_header Host "legacyapp.example.com";
proxy_pass http://localhost:8081;
}
Где 8081 - это номер порта вашего SSH-туннеля (или если вы найдете другой способ доступа к веб-серверу устаревшего приложения), а legacyapp.example.com - это имя хоста вашего устаревшего приложения.
Это будет работать, пока ваш SSH-туннель работает. Довольно шатко для продакшена, но я думаю, что это нужно для настройки разработчика. :-) Вот почему я рекомендую вам покопаться и посмотреть, сможете ли вы получить доступ к устаревшему приложению из своей сети разработки, используя его внутренний IP-адрес, а не внешнее имя хоста.
Надеюсь это поможет.