Nginx Конфигурация обратного прокси заставляет Mojolicious $ self-> req-> url-> to_abs сбрасывать номер порта - PullRequest
Новая
       118

Nginx Конфигурация обратного прокси заставляет Mojolicious $ self-> req-> url-> to_abs сбрасывать номер порта

1 голос
/ 01 мая 2020

Застрял в реализации «быстрой и грязной» функциональности совместного использования ссылок на веб-ресурсы, которая должна работать в соответствии со следующим сценарием:

  • пользователь перечисляет элементы из базы данных, нажимает на правку
  • система открывает диалоговое окно редактирования с выбранным приложением
  • система представляет ссылку на этот элемент в этом экземпляре приложения, так что с помощью нескольких вкладок пользователь может Ctrl + C или Cmd + C it ...

Итак, у меня есть следующий код в шаблоне mojolicious, который Mojolicious отлично переводит в правильный абсолютный URL-адрес при запуске без nginx обратный прокси: 

 <input id="modal-dia-share-lnk" @focus="this.document.execCommand('selectAll',false,null)"
 :value="'<%=  $self->req->url->to_abs =%>?&'+'with=id-eq-'+this.$attrs.id.replace('dia-','')" readonly>

, что означает что-то вроде:

http://host-name:8082/qto/list/monthly_issues_202004?&with=id-eq-200327122837, который имеет порт

, но во время работы за обратным прокси-сервером он пропускает порт, поэтому, даже если я работаю на порту 441, сгенерированный URL имеет НЕ порт http://qto.fi/qto/list/monthly_issues_202004?&with=id-eq-200325163720

Что является неприемлемым в этом установка , потому что уровень приложения Mojo для dev должен прослушивать порт 441 , а уровень приложения Mojo для prd должен прослушивать порт 443

На самом деле вы можете получить сценарий как в:

  • экземпляре слоя приложения qto в dev
  • экземпляре слоя приложения qto в prd

, просто нажав кнопку ОК, чтобы войти в систему с анонимным пользователем по умолчанию ...

Я мог бы создать URL-адрес на основе существующей конфигурации приложение, но я предполагаю, что должен быть быстрый nginx взлом, чтобы фактически включить порт с помощью некоторого регулярного выражения в директиве location или что-то в этом роде ...

Это обратный прокси conf : 

server {

  listen 443 ssl;
  server_name qto.fi;
  server_tokens off;

  ssl_certificate /etc/letsencrypt/live/qto.fi/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/qto.fi/privkey.pem;

  location / {
    proxy_pass http://localhost:8080/;
    proxy_http_version 1.1;
    proxy_pass_header Authorization;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_read_timeout 10s;
  }
}

также существует следующий http conf для сайта разработчика: 

server {
    listen 78;
    listen [::]:78;

    server_name qto.fi;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $remote_addr;

    location / {
        proxy_pass http://localhost:8078/;

         proxy_http_version 1.1;
         proxy_set_header Upgrade $http_upgrade;
         proxy_set_header Connection "upgrade";
         proxy_set_header Host $host;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header X-Forwarded-Proto $scheme;
         proxy_set_header X-Real-IP        $remote_addr;
         proxy_set_header X-Forwarded-For
         $proxy_add_x_forwarded_for;
         # ....

    }
}

Ответы [ 2 ]

2 голосов
/ 05 мая 2020

Добавьте порт в заголовок хоста в обратном прокси-сервере nginx: 

proxy_set_header Host $host:443;

ИЛИ 

proxy_set_header Host $host:$server_port;
1 голос
/ 05 мая 2020

Обходной путь, основанный на ответе из ttubrian , но, тем не менее, не совсем реальным решением может быть

для создания URL-адреса на proxy_set_header Host $host:78;

, поэтому https будет выглядеть следующим образом: 

server {

  listen 441 ssl;
  server_name qto.fi;
  server_tokens off;

  ssl_certificate /etc/letsencrypt/live/qto.fi/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/qto.fi/privkey.pem;

  location / {
    proxy_pass http://localhost:8078/;
    proxy_http_version 1.1;
    proxy_pass_header Authorization;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Scheme $scheme;
    proxy_set_header Host $host:78;
    proxy_read_timeout 10s;
  }
}

, который генерирует следующий тип URL:

http://qto.fi:78/qto/list/problems?&with=id-eq-200325184202

и добавление http -> применение https в http dev conf:

return 301 https://$host:441$request_uri;

, поэтому dev conf будет выглядеть следующим образом: 

 server {
    listen 78;
    listen [::]:78;

    server_name qto.fi;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $remote_addr;

    return 301 https://$host:441$request_uri;

    location / {
        proxy_pass http://localhost:8078/;

         proxy_http_version 1.1;
         proxy_set_header Upgrade $http_upgrade;
         proxy_set_header Connection "upgrade";
         proxy_set_header Host $host;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header X-Forwarded-Proto $scheme;
         proxy_set_header X-Real-IP        $remote_addr;
         proxy_set_header X-Forwarded-For
         $proxy_add_x_forwarded_for;
...