Запросы POST, отправленные https в Tomcat через обратный прокси-сервер Apache, возвращают статус 403 в https ⇐ Apache

[Гость]

Конфигурация: Незащищенная серверная часть (Sringboot 3) развертывается на сервере Tomcat 10 (java 17). Интерфейс (Angular 15) развертывается на веб-сервере Apache 2.4.

Веб-сервер также служит обратным прокси-сервером, позволяющим обойти запрет на выполнение запросов Ajax в соответствии с той же политикой безопасности источника, что и совместное использование ресурсов между источниками (CORS). Без обратного прокси-сервера серверная часть недоступна для внешнего интерфейса.

Http: Эта конфигурация отлично работает, когда браузер обращается к интерфейсу через http.

Https: Эта конфигурация также работает, когда браузер обращается к интерфейсу https для выполнения кода JavaScript (Angular), а также при отправке и обработке ответа, возвращаемого веб-сервером из запросов GET. С другой стороны, когда интерфейс отправляет запрос POST на веб-сервер (apache), веб-сервер возвращает 403 (запрещено). Вот что мы видим на вкладке «сеть» браузера (devtools):

Заголовок: URL-адрес запроса: https://letstryfront.com/api/genjournal ... =0&size=10. Метод запроса:POST Код состояния: 403 Запрещено Удаленный адрес: 192.168.56.105:443 Политика реферера: строгое происхождение при перекрестном происхождении Заголовок ответа: Соединение: Keep-Alive Тип контента:текст/обычный Дата:Пт, 29 декабря 2023 г., 09:29:11 по Гринвичу Keep-Alive: тайм-аут = 5, макс = 100 Сервер: Apache/2.4.58 (Unix) OpenSSL/3.2.0 Кодирование передачи: фрагментированное Принять: application/json, text/plain, */* Accept-Encoding:gzip, deflate, br Accept-Language:en-GB,en-US;q=0.9,en;q=0.8 Соединение: поддерживать активность Длина контента:2 Тип контента: приложение/json Хост: letstryfront.com Происхождение: https://letstryfront.com Реферер: https://letstryfront.com/journal Sec-Ch-Ua:"Not_A Brand";v="8", "Chromium";v="120", "Google Chrome";v="120" Сек-Ч-Уа-Мобильный:?0 Сек-Ч-Уа-Платформа:"Windows" Sec-Fetch-Dest: пусто Sec-Fetch-Mode:cors Sec-Fetch-Site: того же происхождения Пользовательский агент: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, например Gecko) Chrome/120.0.0.0 Safari/537.36 Удивительно, но когда запрос POST отправляется с использованием Curl, веб-сервер обычно выполняет его с 200 (успех).

curl -X POST -v "https://letstryfront.com/api/genjournal ... =5&size=10" -H "принять: */*" -H "Тип контента: application/json " -d "[ { \"sortField\": \"lineno\", \"sortDirection\": \"asc\", \"orderSeq\": 0 }]" -o Journallines.json --ssl-no -отозвать В журналах tomcat10 указано «Завершено 200 ОК», но ошибки 403 «Запрещено» нигде нет.

Однако журналы веб-сервера Apache показывают возврат 403 от серверной части, работающей на Tomcat: Статус из бэкэнда: 403, ссылка: https://letstryfront.com/journal

Вот конфигурация виртуальных хостов на уровне сервера Apache:

Имя сервера letstryfront.com ServerAlias ​​*.letstryfront.com SSLProxyEngine включен SSLProxyCheckPeerCN Выкл. SSLProxyCheckPeerName выключено SSLProxyVerify нет DocumentRoot "/srv/http/letstryfront" Индексы опций FollowSymLinks MultiViews Разрешить со всех Разрешить переопределить все Требовать все предоставленные ProxyPreserveHost включен ProxyPass /api http://localhost:8080/lettrysome/api ProxyPassReverse /api http://localhost:8080/letstrysome/api Proxypass /external/geocode/ https://maps.googleapis.com/maps/api/geocode/ ProxypassReverse /external/geocode/ https://maps.googleapis.com/maps/api/geocode/ Проксипасс /external/v1/ https://api.open-meteo.com/v1/ ProxypassReverse /external/v1/ https://api.open-meteo.com/v1/ Перезаписать двигатель включен RewriteCond %{REQUEST_URI}$1 внешний/геокод/json RewriteCond %{QUERY_STRING} ^(адрес=.*&)key=.*$ RewriteRule ^ %{REQUEST_URI}?%1key=REMOVED [NE,PT,END] Уровень журнала трассировки2 Журнал ошибок "/var/log/httpd/letstryfront.com-error_log" CustomLog "/var/log/httpd/letstryfront.com-access_log" общий Имя сервера letstryfront.com ServerAlias ​​192.168.56.105 *.letstryfront.com SSLEngine включен SSLCertificateFile /etc/ssl/certs/letstryfront.com.crt SSLCertificateKeyFile /etc/ssl/private/letstryfront.com.key SSLCACertificatePath /etc/ssl/certs/ SSLProxyEngine включен SSLProxyCheckPeerCN Выкл. SSLProxyCheckPeerName выключено SSLProxyVerify нет DocumentRoot "/srv/http/letstryfront" Индексы опций FollowSymLinks MultiViews Разрешить со всех Разрешить переопределить все Требовать все предоставленные ProxyPreserveHost включен ProxyPass /api http://localhost:8080/lettrysome/api ProxyPassReverse /api http://localhost:8080/letstrysome/api Proxypass /external/geocode/ https://maps.googleapis.com/maps/api/geocode/ ProxypassReverse /external/geocode/ https://maps.googleapis.com/maps/api/geocode/ Проксипасс /external/v1/ https://api.open-meteo.com/v1/ ProxypassReverse /external/v1/ https://api.open-meteo.com/v1/ Перезаписать двигатель включен RewriteCond %{REQUEST_URI}$1 внешний/геокод/json RewriteCond %{QUERY_STRING} ^(адрес=.*&)key=.*$ RewriteRule ^ %{REQUEST_URI}?%1key=REMOVED [NE,PT,END] Уровень журнала трассировки4 Журнал ошибок "/var/log/httpd/letstryfront.com-tls-error_log" CustomLog "/var/log/httpd/letstryfront.com-tls-access_log" общий Я несколько раз менял конфигурацию виртуального хоста https (443). Я полагаю, что можно принудительно пройти POST-запросы. Я все еще тестирую. Другим решением может быть действие на внутреннем уровне. Если у кого-нибудь есть решение, будь то на внутреннем уровне (Springboot 3) сервера Tomcat 10 или конфигурации Apache 2.4, мне было бы интересно.