Acumatica за обратным прокси-сервером вызывает проблемы с GetFile.ashx - PullRequest
Новая
       5

Acumatica за обратным прокси-сервером вызывает проблемы с GetFile.ashx

1 голос
/ 26 февраля 2020

Я использую свои экземпляры Acumatica для разработки за обратным прокси-сервером, состоящим из IIS с маршрутизацией запросов приложений. В большинстве случаев они работают и ведут себя, как и ожидалось, однако у меня возникают проблемы с изображениями, например, логотипами, фотографиями инвентаря и т. Д. c. Проблема заключается в том, что при первой загрузке URL-адрес, предоставленный клиенту, является абсолютным. Если перемещаться между ветвями, то lo go url переключается на относительный URL-адрес, и изображение отображается правильно.

, если вам нужен пример, это URL-адрес тестового экземпляра.

https://2019r2.acumatica.govelocit.com/test20r1

пользователь: admin

pass: P@ssword1

при входе в lo go будет отображаться значок разорванной ссылки Изображение с Broken Link , если вы переключаетесь на новую ветку, отображается lo go. Рабочее изображение

Если вы переключитесь обратно на ветку, которую вы начали с lo, go все равно будет отображаться нормально. Это просто начальная проблема с загрузкой.

Мысли?

1 Ответ

2 голосов
/ 26 февраля 2020

Проблема здесь в том, что абсолютный URL создается не с использованием текущей схемы URL, а схемы, которая была вызвана сайтом. А поскольку вы звоните на сайт с обратного прокси-сервера через http, сгенерированная для изображений ссылка также является http и поэтому не может быть загружена. Кроме того, вы получаете предупреждение о безопасности, так как вы вызываете http-контент через сайт по https. как здесь и если вы просто отредактируете схему URL в браузере, появится изображение - здесь вы увидите изображение

Есть как минимум 2 хороших решения, которые можно предложить:

  1. Укажите свой обратный прокси на сайте HTTPS. Это довольно простое решение, которое, однако, может принести небольшую головную боль в конфигурации, если вашему обратному прокси-серверу не понравится самозаверяющий сертификат IIS. Это также не позволит анализировать запросы, так как все транспорты будут зашифрованы.

  2. Другое решение немного более сложное и позволит вам позвонить на сайт http и заставить его думать, что вы звонит https. Для этого вам потребуется установить заголовок X-Forwarded-Proto как https в конфигурации обратного прокси-сервера. К сожалению, не знакомы с Application Request Routing 3.0, для лучшего понимания расположение прокси NginX будет выглядеть так: 

    location ~ ^/(MySite){
    proxy_pass http://localhost:82;           //note, you are calling https here
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto https;  //here you are tricking the site
}
...