2016-07-25 2 views
0

Ich habe einen httpd-Server konfiguriert und funktioniert. Der Server gibt "Es funktioniert" zurück und ich kann sehen, dass das SSL korrekt installiert ist.Moqui läuft in Jetty-Container hinter httpd zurück Fehler-Rendering-Bildschirm

Der nächste Schritt, den ich unternahm, war das Konfigurieren des Reverseproxys, so dass die Benutzeranforderungen umgeleitet werden und ich mehr Apps von Kunden in einer Subdomain haben kann. Die httpd-Konfiguration (siehe unten), die ich benutze, gehört mir nicht, ich versuche nur, sie neu zu konfigurieren, um für mich zu funktionieren. Aber bisher ohne großen Erfolg. Es gibt Anweisungen, die möglicherweise falsch sind, aber ich habe nicht versucht, etwas zu kommentieren.

#Apache is listening on port 443 
Listen 443 
SSLSessionCache   shmcb:c:/Apache24/logs/shmcb_cache(512000) 
SSLSessionCacheTimeout 300 
Mutex default ssl-cache 
SSLRandomSeed connect builtin 
SSLCryptoDevice builtin 
<VirtualHost *:443> 
    #ProxyPreserveHost On 
    SSLProxyEngine On 

    ServerName XXXX.sk 
    ServerAdmin admin 

    # Logs 
    ErrorLog /var/log/rsk_error_log 
    TransferLog /var/log/rsk_access_log 

    # Server Certificate and Private Key: 
    SSLCertificateFile /ssl/certificate.crt 
    SSLCertificateKeyFile /ssl/private.key 
    SSLCertificateChainFile /ssl/chain.crt 

    #Include conf/extra/proxy-443-to-8890.conf 

    ProxyPass /customer http://172.17.0.4:8080 
    ProxyPassReverse /customer http://172.17.0.4:8080 
</VirtualHost> 

Nun, wenn ich schreibe XXXX.sk/customer erhalte ich eine Antwort, die ein Login-Bildschirm, aber es falsch gemacht wird, wird die CSS nicht verwendet. Es treten viele Fehler auf. Wenn ich mich anmelde, wird keine Antwort zurückgegeben und die URL ist beschädigt.

Kann jemand von Ihnen, mit httpd in einem Reverse-Proxy-Modus, teilen Sie bitte Ihre Konfigurationen, zumindest ein Teil von ihnen?

+0

Wie sieht Ihre XML-Datei für moqui conf aus, insbesondere das webapp-Element? Dort konfigurieren Sie das URL-Schreiben. Wenn die virtuellen Hosts von httpd behandelt werden und Sie mehrere moqui-Instanzen haben, ist es am besten, den Hostnamen für jeden in den webapp-Elementattributen explizit anzugeben. Wenn eine Instanz von moqui mehr als einen virtuellen Host behandelt, ist es ein wenig komplizierter, Sie müssen sicherstellen, dass der Hostname durchgelassen und verwendet wird. –

+0

Ich begann mit der Standardkonfiguration. Das heißt, kein http-port + http-host und kein https-port + https-host, mit https-enabled = false (Ergebnis war eine Login-Seite ohne CSS und HTTPS in der URL). Jetzt habe ich http-port = 80, http-host = XXXX.sk/customer und https-port = 443, https-host = XXXX..sk/customer und https-enabled = true. Das Ergebnis ist kein Anmeldebildschirm. – mrovnanik

+0

Im letzten Fall (mit https-enabled = true), der Fehler in Moqui Log sagt: "Bildschirm an Ort [Komponente: //webroot/screen/webroot.xml], die Teil von [[Fehler, NotFound]] Unter dem Bildschirm [component: //webroot/screen/webroot.xml] wird eine verschlüsselte/sichere Verbindung benötigt, die Anfrage ist jedoch nicht sicher. – mrovnanik

Antwort

0

Das Standard-Webroot in der Basiskomponente ist Mapping zu/in URL. Alle Ressourcen wie CSS, js usw. verwendet "/" URL zu erstellen, so dass, obwohl die proxying

ProxyPass /customer http://172.17.0.4:8080 

Die tatsächliche js Lage

/lib/jquery/jquery-ui.min.css 

nicht

/customer/lib/jquery/jquery-ui.min.css 

ist immer noch Damit es funktioniert, benötigt der Reverse-Proxy mehr unordentliche Proxy-Pass-Konfigurationen.

So wird die Verwendung eines zusätzlichen Pfades zum Proxy des Webroot nicht empfohlen.

+0

Die proxyPass-Direktive wird mit dem Ziel verwendet, die eingehende Anfrage an eine bestimmte App zu leiten (in diesem Fall Jetty im eingebetteten Modus auf der angegebenen IP-Adresse). Dies scheint korrekt zu funktionieren, im Sinne von Redirect. Wenn ich den HTML-Code auschecke (wenn der Bildschirm falsch angezeigt wird), scheint das einzige Problem zu sein, nicht der zusätzliche/Kunde, sondern die Tatsache, dass die Anwendung mit http geantwortet hat. Und nicht https. – mrovnanik

+0

Von dem, was ich gelernt habe, läuft der Standard-Jetty-Container http Port auf 8080. Aber es sollte auf https ausgeführt werden, um als sicher zu gelten. Das sagt mir das Logbuch. In Zeiten von Winstone gab es einen Befehlszeilenparameter --httpsPort, um einen https-Port zu öffnen, der standardmäßig geschlossen war. Auf Jetty habe ich nicht herausgefunden, wie es geht.Ich mag mich irren, aber so sehe ich es jetzt. – mrovnanik

+0

Ich habe diesen Artikel als Tutorial verwendet. Bitte sehen Sie sich die ProxyPass und ProxyPassReverse im Beispielfall weiter im Text hinter diesem Link an: https://oracle-base.com/articles/misc/apache-reverse-proxy-configuration – mrovnanik

Verwandte Themen