0

I have an httpd server configured and working. The server returns "It works" and I can see the SSL is installed correctly.

The next step I undertook was configuring the reverse proxy, so that the users requests are redirected and I can have more customers' apps under one subdomain. The httpd configuration (shown below) I use is not mine, I am just attempting to reconfigure it to work for me. But with no big success up to now. There are directives that may be incorrect, but I have not tried commenting anything out.

#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>

Now when I type XXXX.sk/customer I receive a response which is a login screen, but it is incorrectly rendered, the CSS is not used at all. There are many errors appearing. When I log in, no response is returned and the URL is corrupted.

Can any of you, using httpd in a reverse proxy mode, please share your configs, at least a part of them?

mrovnanik
  • 123
  • 9
  • What does your moqui conf XML file look like, specifically the webapp element? That is where you configure the URL writing. If the virtual hosts are handled by httpd and you have multiple moqui instances then it's best to explicitly specify the hostname for each in the webapp element attributes. If one instance of moqui is handling more than one virtual host it's a little more complicated, you have to make sure the hostname is getting passed through and used. – David E. Jones Jul 26 '16 at 06:24
  • I started with the default configuration. That means no http-port+http-host and no https-port+https-host, with https-enabled=false (outcome was a login page with no CSS and HTTPS in the URL). Now I have http-port=80, http-host=XXXX.sk/customer and https-port=443, https-host=XXXX..sk/customer and https-enabled=true. The outcome is no login screen. – mrovnanik Jul 26 '16 at 15:30
  • In the last case (with https-enabled=true), the error in moqui log says: "Screen at location [component://webroot/screen/webroot.xml], which is part of [[error, NotFound]] under screen [component://webroot/screen/webroot.xml] requires an encrypted/secure connection but the request is not secure, sending redirect to secure". – mrovnanik Jul 26 '16 at 15:34
  • The URL in the browser changes from https://XXX.sk/customer (https) to https://XXXX.sk/customer/apps/AppList (https). – mrovnanik Jul 26 '16 at 15:55

1 Answers1

0

The default webroot in base-component is mapping to / in url. All of resources like css, js etc is using "/" to build url, So Although the proxying is 

ProxyPass /customer http://172.17.0.4:8080

The actual js location is still 

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

not 

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

To make it work, the reverse proxy would need more messy location proxy_pass configurations.

So using additional path to proxy the webroot is not suggested.

Jimmy Shen
  • 240
  • 1
  • 12
  • The proxyPass directive is used with the aim to route the incoming request to a specified app (in this case Jetty in embedded mode on the provided IP). This seems to work correctly, in the meaning of redirecting. When I check out the html code (if the incorrectly displayed ligin screen), the only problem seems to be, not the additional /customer, but rather the fact that the application replied with http. And not https. – mrovnanik Jul 27 '16 at 05:56
  • From what I have learnt, the default Jetty container is running http port on 8080. But it should be running on https, to be considered secure. That's what the log says, to me. In times of Winstone, there was a command line parameter --httpsPort to open an https port, which was closed by default. On Jetty, I haven't figured out how to do it. I may be wrong, but this is how I see it now. – mrovnanik Jul 27 '16 at 06:04
  • I used this article as a tutorial. Please, check out the proxyPass and proxyPassReverse in the sample case further in the text behind this link: https://oracle-base.com/articles/misc/apache-reverse-proxy-configuration – mrovnanik Jul 27 '16 at 06:11