nginx Reverse Proxy und Apache

[_RM_]

Hallo Forum,

ich habe mir nginx als Reverse Proxy mit HTTPS konfiguriert und leite bestimmte Anfragen über unverschlüsseltes HTTP zu einem lokalen Apache weiter auf dem diverse eigene und Third-Party PHP Apps laufen.
Grundsätzlich funktioniert das auch wie gewünscht.

Mein Problem ist nun, dass mindestens eine der Applikationen "falsche" URLs generiert und ausliefert, und zwar alle mit http://.
Die App generiert die URLs scheinbar so, wie das ursprüngliche Protokoll war (was ja Sinn macht). Das Problem ist, dass diese URLs dann auch nur mit http:// am Client ankommen und ein Client/Browser dann z.B. bei einem HTTP Redirect 301 oder 302 die URL entsprechend "falsch" aufruft. Grundsätzlich ist das nicht so tragisch, weil im nginx http auf https umgeleitet wird, aber eine meiner Applikationen verwendet <iframe>'s und wenn die Hauptseite HTTPS ist und der iframe dann HTTP Content hat, verweigert der Browser die Anfrage (Mixed Block). Generell möchte ich auch eine "schöne" Lösung, sprich es soll einfach alles HTTPS sein.

Meine Frage ist nun, ob ich den Apache auch zu HTTPS machen muss/soll und ob dafür ein Self-Signed Cert reicht oder ob es vielleicht noch einen anderen Weg gibt, um dem Apachen irgendwie HTTPS/SSL vorzutäuschen. Ich denke da z.B. an irgendwelche Header die man in nginx setzen könnte.
Auf jeden Fall kann ich nicht alle Applikationen umschreiben, da manche 3rd-Party sind (z.B. phpBB Forum und MediaWiki).

mfG
RM

 

[madmax2010]

welche anwendung? warum apache+nginx? normal macht man eher php-fpm+nginx

HTTP Content hat, verweigert der Browser die Anfrage (Mixed Block

das verhalten ist korrekt.
Optimal werden alle inhalte unter der selben domain ausgeliefert. Und keine unverschluesseltn Inhalte.

zeig doch mal die Configs

 

[Nixdorf]

Falls die Anwendungen es nicht erlauben, HTTPS in den erzeugten Links zu erzwingen, kann das $_SERVER-Array so manipuliert werden, dass die Anwendung glaubt, sie wäre via HTTPS aufgerufen worden. Vielfach kann man das am besten am Anfang der Config-Datei der Anwendung machen.

 

[KillerCow]

Wenn man mit Reverseproxies arbeitet, macht es Sinn, Infos der Originalanfrage per Header mitzuschicken. Siehe hier: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Forwarded

Daraus kann deine Anwendung alle relevanten Infos ziehen und Links korrekt zusammenbauen. Ggf. schickst du in einem weiteren Header noch den gewünschten Domainnamen mit.

"Vernünftige" Anwendungen werten solche Header von alleine aus und/oder lassen sich gezielt für die Nutzung hinter Reverseproxies konfigurieren und verhalten sich dann korrekt. Aber manchmal ist das ein Krampf, kenne ich nur zu gut

 

[Nixdorf]

Wenn man mit Reverseproxies arbeitet, macht es Sinn, Infos der Originalanfrage per Header mitzuschicken.

Ich ging davon aus, dass diese Informationen alle schon entsprechend konfiguriert sind. Aber ja, genau das macht man. Und wenn dann die Anwendung nicht automatisch darauf reagiert, dann kann man selber diese Daten im $_SERVER-Array wieder so umschreiben, dass die Anwendung es so zu sehen bekommt, als wäre der Proxy gar nicht da.

 

[_RM_]

warum apache+nginx?

Zum einen aus Spaß, aber aktuell eigentlich hauptsächlich, weil ich keine Lust habe alles umzukonfigurieren und mich mit der nginx-Konfig noch null auskenne.
nginx will ich, um dafür ein Modul zu schreiben.
Weiters wird bald eine ASP.NET oder Blazor App dazukommen auf die dann auch weitergeleitet werden soll.

zeig doch mal die Configs

Der relevante Teil wird vermutlich dieser sein

    location / {
        proxy_pass         http://localhost:8080;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection $connection_upgrade;
        proxy_set_header   Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;

        client_max_body_size    10m;
        client_body_buffer_size 128k;
        proxy_connect_timeout   90;
        proxy_send_timeout      90;
        proxy_read_timeout      90;
        proxy_buffers           32 4k;

        proxy_redirect          off;
        proxy_set_header        X-Real-IP $remote_addr;

        #limit_req  zone=one burst=10 nodelay;
    }

Das $http_upgrade ist in der http {} Sektion noch wie folgt definiert:

http {
    
    server_names_hash_bucket_size       64;
    
    map $http_upgrade $connection_upgrade {
        default Upgrade;
        ''      close;
    }
    
    # diverse andere config die schon da war und von mir nicht geändert wurde
}

Forwarded Header werden also offensichtlich eh schon mitgeschickt. Gibt es noch andere wichtige, die man mitschicken sollte?