Umleitungen Rewriting den Port schließen verwendet, um den Dienst zuzugreifen

Question

ich ein Setup wie diese:

Ein Benutzer mit meiner Vagrant Entwicklungsumgebung arbeiten greift localhost:8080 auf ihrer Host-Maschine, die in Vagrant weitergeleitet wird zu NGINX läuft auf localhost:80 auf dem Gast. Einige Anforderungen werden an meinen Anwendungsserver weitergeleitet, der unter localhost:8080 auf dem Gast ausgeführt wird, und einige sind statische Dateien, die von NGINX bereitgestellt werden.

Eine seltsame Sache passiert, wenn ich auf meine Website zugreifen. Ich habe eine Anmeldeseite, die auf Erfolg umleitet, und die URL wird von http://localhost:8080/login zu http://localhost:80/login umgeschrieben.

Hier ist meine NGINX Konfiguration für den Standort:

upstream appserver { 
    server 127.0.0.1:8080; 
} 

upstream production { 
    server www.mysite.com:443; 
} 

server { 
    listen 80 default_server; 
    server_name _; 

    client_max_body_size 20M; 

    access_log /var/log/nginx/project.access.log; 
    error_log /var/log/nginx/project.error.log; 

    index /index; 

    location ~ ^(/js/testpage.js) { 
     alias /vagrant/artifacts/www/js/testpage.js; 
    } 

    location ~ ^(/test/js/app.js) { 
     alias /vagrant/test/js/app.js; 
    } 

    location ~ /test/js/app_router.js { 
     alias /vagrant/test/js/app_router.js; 
    } 

    location ~ /test/js/app_layout_controller.js { 
     alias /vagrant/test/js/app_layout_controller.js; 
    } 

    location ~ /test/js/apps/navbar/sections/layout/navbar_layout_controller.js { 
     alias /vagrant/test/js/apps/navbar/sections/layout/navbar_layout_controller.js; 
    } 

    location ~ /test/js/apps/navbar/sections/navbar/navbar_options_view.js { 
     alias /vagrant/test/js/apps/navbar/sections/navbar/navbar_options_view.js; 
    } 

    location ~ /test/js/apps/navbar/sections/navbar_all_views.js { 
     alias /vagrant/test/js/apps/navbar/sections/navbar_all_views.js; 
    } 

    location ~ ^/test/js/apps/(.*/testpage_.*\.js)$ { 
     alias /vagrant/test/js/apps/$1; 
    } 

    location ~ ^/test/js/(.*)$ { 
     alias /vagrant/js/$1; 
    } 

    location ~ ^/build/js/(.*)$ { 
     alias /vagrant/artifacts/www/js/$1; 
    } 

    location ~ ^/build/css/(.*)$ { 
     alias /vagrant/artifacts/www/css/$1; 
    } 

    location ~ ^/(.*main.*)\.[@\-_\/\d\w]+\.(js|css)$ { 
     alias /vagrant/$1.$2; 
    } 

    location ~ ^/(css|js|fonts|favicon.ico) { 
     root /vagrant; 
    } 

    location ~ ^/receipts/js/(.*)$ { 
     alias /vagrant/receipts/js/$1; 
    } 

    location ~ ^/bower_components/(.*)$ { 
     alias /vagrant/bower_components/$1; 
    } 

    location ~ ^/login-promo/ { 
     access_log off; 
     proxy_pass https://production; 
     proxy_set_header X-Real-IP $remote_addr; 
     proxy_set_header Host $host; 
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
    } 

    location ~ ^/(admin|login|logout|index|build|testpage|receipts|open|reset|resetpage|privacy|change|activeUser|personPrivacyAcceptances) { 
     access_log off; 

     proxy_pass http://appserver; 
     proxy_set_header X-Real-IP $remote_addr; 
     proxy_set_header Host $host; 
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
    } 
} 

Ich bin nicht sicher, wo die Umleitung tatsächlich herkommt, könnte es aus dem App-Server-Backend oder von dem vorderen Ende JavaScript kommen. Gibt es eine Möglichkeit, dass ich sicherstellen kann, dass alle Redirects den vom zugreifenden Client verwendeten Port verwenden?

---

Update: Einfach das Hinzufügen eines <a href="/login">login</a> Link auf die Stammseite und versuchen zu navigieren mit dem Link mich zu http://localhost:80/login anstatt http://localhost:8080/login umleitet.

Answer 1

Dies scheint indem Umleitungen falsch im Anwendungscode verursacht worden zu sein.

Wenn Sie eine ähnliche Architektur wie oben haben und das Problem auftritt, ist es wahrscheinlich, dass der Grund für das Problem auf einen naiven Versuch der Umleitung ohne Berücksichtigung der Host Kopfzeile zurückzuführen ist.

Ihre Bewerbung hinter nginx eine Anfrage wie folgt sieht:

GET /path/to/resource 
Host: virtualinstance:8888 

Leider ist es etwas tut, stumm und rekonstruiert die Host Header ohne Berücksichtigung der Umleitung, wenn es baut die Umleitung, anstatt für den Host entscheiden und Port, den es kennt, benutzt es. Der Code, der meine Redirect anbrach sah etwa so aus:

return redirect("http://" + getHostName() + "/" + getPath()) 

Erstens, es ist schlecht, dass es das Protokoll Hardcodes, aber schlimmer noch, dass es eine Methode verwendet, die ohne Rücksicht auf den Port des Host-Namen. Dies würde eine Weiterleitung an http://localhost/path anstelle von http://localhost:8888/path zurückgeben.

Entwickler, das ist, warum Sie immer die Host Header als Quelle für Ihre Umleitung verwenden sollten:

return redirect("%s://%s/%s" % (getProtocol(), getHeader("Host"), 
    getPath()) 

Dies macht eine vernünftige Umleitung, das ursprüngliche Protokoll, Volltext von Host und den Pfad.

Answer 2

Dies ist wahrscheinlich ein unerwünschter Nebeneffekt, wenn der Nginx-Port des Gasts auf einen anderen Host geleitet wird.

Siehe http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_redirect

Die Deaktivierung des Proxy-Umleitung in der letzten Position Block sollte es tun: Sein on standardmäßig

proxy_redirect off; 

Answer 3

Es ist wahrscheinlich aufgrund port_in_redirect geschieht. Siehe: http://wiki.nginx.org/HttpCoreModule#port_in_redirect

Deaktivieren, würde wahrscheinlich einige der Verwirrung, warum der Port angewendet wird, zu stoppen.

Von dort ist es so einfach wie die entsprechenden host_port oder remote_port in Ihren Proxy-Weiterleitungen, wie nötig. Wenn man sich die Konfiguration anschaut, sieht es so aus, als wäre man mit den Kernmodulvariablen vertraut, es wäre ziemlich einfach, diese Variablen einzubeziehen.

See:

http://wiki.nginx.org/HttpCoreModule#.24remote_port http://wiki.nginx.org/HttpCoreModule#.24server_port