Блог

Главная - Вопросы по программированию - Перенаправления HTTPS теряются из-за туннелирования

Перенаправления HTTPS теряются из-за туннелирования

#java #ssl #nginx #jakarta-ee

#java #ssl #nginx #джакарта-ee

Вопрос:

При выполнении интеграционных тестов нашей системы я столкнулся с проблемой, заключающейся в том, что использование приложения JSF через https всегда возвращает 400 (запрещено) при возврате из перенаправления после POST из-за преобразования в http. Это происходит только в том случае, если запрос выполняется через туннельное соединение через jumphost.

Итак, вот настройка:

  • На сервере работает WildFly с приложением JSF и nginx, который обрабатывает входящие запросы https от 443 и передает их на порт WildFly
  • Сервер находится в закрытой сети, доступ к которой возможен через jumphost, к которому снова можно получить доступ с моего компьютера
  • SSH-соединение устанавливает туннель между локальным портом на моем компьютере и портом 443 на сервере
  • Браузер запрашивает https://localhost:myport

Теперь, всякий раз, когда я что-то публикую, например, логин, перенаправленный ответ возвращается с http scheme и, таким образом, дает мне 400. Если я вручную добавлю https в браузер, на запросы будут даны правильные ответы.

Завиток того же URL-адреса дает мне это:

 curl -i -k https://localhost:8426
HTTP/1.1 302 Found
Server: nginx
Date: Fri, 23 Oct 2020 15:03:52 GMT
Content-Length: 0
Connection: keep-alive
Set-Cookie: INCENTCONTROL_JSESSIONID=[....]; path=/
Location: http://localhost:8426/login.xhtml

Если я делаю то же самое непосредственно с компьютера в сети сервера, все в порядке.

Какое отношение имеет туннелирование к проблеме и есть ли у кого-нибудь идея, как ее преодолеть?

Комментарии:

1. Я мог бы предположить, что проблема заключается в том, что домен, ожидаемый серверным приложением, не является тем доменом, который вы используете, потому что вы туннелируете. Используемый вами домен отображается в квитировании TLS, а также в заголовке хоста и, таким образом, может влиять на поведение сервера. Это также, вероятно, причина, по которой вам нужно использовать -k , т. Е. Игнорировать проблемы с сертификатами, вызванные этим. Вместо этого вы должны заставить curl использовать реальное имя, но с IP-адресом туннеля. --resolve Для этого см. Аргумент curl .

2. @SteffenUllrich Спасибо за подсказку, звучит разумно.