Dear all,
we set up Knowage behind a reverse proxy with TLS. By doing so, we found a minor issue with Knowage when used behind a reverse proxy which we would like to document here/share. I will share some more details than necessary in case someone wants to recreate this https-setup.
Preword:
We have a Knowage Setup in our protected, internal network and would like to give customers access to the webinterface without exposing the machine. We also want that access to be TLS (HTTPS) secured; since Java's Keystorage is a tad more complex and often not flexible enough for our needs, we decided to use a reverse proxy instead. This matched our setup well, since we already had one that was in use for other webservices (by using Let's Encrypt there, we do not have to worry about encryption and certificate roll outs).
Network setup:
We have two machines:
- One for the reverse proxy (machine R) with two IPs; one public: a.b.c.d, and one private address: x.x.x.4
- One for Knowage (machine K) with one private IP: x.x.x.5
Both machines can communicate through the private network, but K can not be accessed from outside the x.x.x.x-network.
Setup of reverse proxy:
We now installed apache (nginx works well, too) on R, enabled mod_proxy and setup (and enable) this configuration:
<VirtualHost *:80>
ServerName knowage.domain.tld
ServerAdmin postmaster@domain.tld
DocumentRoot /var/www/knowage/
Alias /.well-known /var/www/letsencrypt/knowage/.well-known
<Directory /var/www/letsencrypt/knowage>
Options -Indexes +FollowSymLinks -MultiViews
AllowOverride All
Order Allow,Deny
Allow from All
</Directory>
<Directory /var/www/knowage>
AllowOverride All
Options -Indexes +FollowSymLinks -MultiViews
</Directory>
ProxyRequests off
ProxyPreserveHost on
ProxyPass /knowage http://x.x.x.5:8080/knowage
ProxyPass /knowagecockpitengine http://x.x.x.5:8080/knowagecockpitengine
ProxyPass /knowagedataminingengine http://x.x.x.5:8080/knowagedataminingengine
# Optional. Uncomment this and create the .htpasswd file to add http basic auth
#<Location /knowage>
# AuthType Basic
# AuthName "Business Intelligence Basic Auth"
# AuthBasicProvider file
# AuthUserFile "/var/www/knowage/.htpasswd"
# Require valid-user
#</Location>
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
All italic written parts have to be replaced with your actual data, of course.
After having enabled this, reload your webserver.
Make sure that your subdomain is valid, points to a.b.c.d and can be called. Test it by calling knowage.domain.tld. This should work, but probably not yet yield anything too useful. If you call http://knowage.domain.tld/knowage, you should get a server error message (or/and, if you enabled the basic auth, be asked for the credentials before you see the error message).
Afterwards, install letsencrypt, create /var/www/knowage and /var/www/letsentrypt/knowage/. Call letsencrypt like this:
certbot --authenticator webroot --installer apache \
-w /var/www/letsencrypt/knowage \
-d knowage.domain.tldIt will then get and install the certificates for you. It will also ask if it should only allow secure connections. Acknowledge this.
Setup of Knowage:
Install Knowage as usual (or use your existing instance). Open conf/server.xml in an editor.
Search for host_url - there should be only one match and that line should start with <Environment … . Edit the value to https://knowage.domain.tld .
In the same file, search for 8080. There may be multiple matches, search for the one in the active <Connector …-entry. At the end of this entry, right before the />, add this:
proxyName="knowage.domain.tld"
proxyPort="443"
scheme="https"(Re)start Knowage, access it through https://knowage.domain.tld/knowage
The problem mentioned before:
If you have a trailing backslash in your Apache's reverse proxy configuration line saying ProxyPass (as below), Knowage will display no menu items in the left handed menu (it basically will stay blank).
ProxyPass /knowage http://x.x.x.5:8080/knowage/ # This won't work
This happens because Knowage will get requests like the following one:
"POST /knowage//servlet/AdapterHTTP?PAGE=LoginPage&NEW_SESSION=TRUE HTTP/1.1" 200 71945
For some reason, some of these requests can not be correctly handled by Knowage. We do not know why that is (and we didn't see a matching error message *anywhere* - neither in the logs nor in the browser nor in the browser's debug console), we only found this by pure luck when we were searching for the reason why the page didn't show anything.
Best
Sebastian
