bag-database behind a proxy

[ptulpen]

Hello,
in the readme it is mentioned that the bag-database can also be running behind e.g. haproxy.
In my case I would like to have it running behind an apache webserver for authentication and at a suburl like https://servername/bag
The issue I have is that the page tries to load the resources from https://servername/resources , not https://servername/resources/bag

Is there some value to change the base url? Or is there a change needed in the proxy?

currently my snippet looks like this

      <Location /bag/>
            SSLRequireSSL
            SSLOptions +StdEnvVars
   AuthType openid-connect
    require valid-user

    Options Includes FollowSymLinks
            AllowOverride AuthConfig Limit
            Order allow,deny
            Allow from all
                ProxyPass               http://127.0.0.1:8080
                ProxyPassReverse        http://127.0.0.1:8080
        </Location>

        </VirtualHost>

[pjreed]

Right now, it's a little bit of a pain to have a reverse proxy serve it from a different application root. The easiest way to handle this is probably to build your own Docker image that serves the application from the same path that you want to serve through your proxy.

I think you'll need to:

1. Check out the develop branch
2. Edit the Dockerfile and modify line 25 by changing ROOT to the name of the path where you want to serve it; in your case, bag. For example, the original line looks like:
   COPY --from=base-layer /src/target/*.war /usr/local/tomcat/webapps/ROOT.war
   You should change this to:
   COPY --from=base-layer /src/target/*.war /usr/local/tomcat/webapps/bag.war
3. Build your own Docker image: docker build . -t bag-database:latest
4. Modify the script you're using to start it to use the bag-database:latest image you just made instead
5. Modify the proxy destinations in your Apache config like so:

   ProxyPass               http://127.0.0.1:8080/bag
   ProxyPassReverse        http://127.0.0.1:8080/bag
   

There's probably a better way to fix this so that server handles setting its application path based on the headers in the proxy requests, but that's the best I've come up with in about an hour of investigation.

[ptulpen]

Hello and thanks a lot for your answer,
I tried it, but when I use it with this configuration, I get infinite redirect to https://servename/bag (via http 302 method)

[pjreed]

I know Apache can be pretty picky when it comes to trailing slashes; does changing the location to <Location /bag> make a difference?

[ptulpen]

Yes, that makes a huge difference :)

now most of the page gets redirected, only the websockets are still not working

[pjreed]

Ok, cool. I believe that you can use mod_rewrite to proxy websocket requests based on their headers; for example, this configuration is working for me:

    <Location /bag>
        RewriteEngine on
        RewriteCond %{HTTP:Upgrade} websocket [NC]
        RewriteCond %{HTTP:Connection} upgrade [NC]
        RewriteRule .* "ws://localhost%{REQUEST_URI}" [P]
        ProxyPass http://localhost:8080/bag
        ProxyPassReverse  http://localhost:8080/bag
    </Location>

Here's some more documentation on how that works: https://www.happyassassin.net/2018/11/23/reverse-proxying-websockets-with-apache-a-generic-approach-that-works-even-with-firefox/

[ptulpen]

Still it does give me an error:
In the logs it looks like
"POST /bag/register/279/gdef01gb/xhr_send?t=1578493975845 HTTP/1.1" 403 408 "https://servername/bag/"

I even added in the apache config:
Order allow,deny
Allow from all

strange part is: the page seems to work.
So what are the websockets used for ?

[pjreed]

If you're seeing POST requests in the log, that probably means that the rewrite rule conditions are probably not matching properly, and the connection is not being upgraded to a web socket properly. Could you paste what your Apache config looks like now?

The websocket is used for the status bar at the bottom of the page; normally, when you add new bag files, it displays status updates there when it either successfully parses them or when it encounters errors. If the websocket isn't working, it's actually not a big deal, you will just have to reload the page in order to see any status messages.

[ptulpen]

<VirtualHost *:443 >
ServerName servername.domain.net
ServerAlias servername
SSLEngine on
SSLCertificateFile /etc/ssl/certs/server.cer
SSLCertificateKeyFile /etc/ssl/private/server.pem
ProxyPreserveHost on

<Location /bag>
    RewriteEngine on
   RewriteCond %{HTTP:Upgrade} websocket [NC]
    RewriteCond %{HTTP:Connection} upgrade [NC]
    ProxyPass http://localhost:8080/bag
    ProxyPassReverse  http://localhost:8080/bag
    ProxyPass               http://127.0.0.1:8080/bag
    ProxyPassReverse        http://127.0.0.1:8080/bag
</Location>

[pjreed]

Ah, I think you're missing a RewriteRule. Also, the second ProxyPass/ProxyPassReverse directives are probably unnecessary. Try this:

<Location /bag>
    RewriteEngine on
    RewriteCond %{HTTP:Upgrade} websocket [NC]
    RewriteCond %{HTTP:Connection} upgrade [NC]
    RewriteRule .* "ws://localhost%{REQUEST_URI}" [P]
    ProxyPass http://localhost:8080/bag
    ProxyPassReverse  http://localhost:8080/bag
</Location>

[ptulpen]

Ah, must have been lost while trying around
I also tried with
RewriteRule .* "ws://localhost:8080%{REQUEST_URI}" [P]
But the issues remain

[ptulpen]

I tried now with debug more for the rewrite on:
[Tue Jan 14 17:13:28.338739 2020] [rewrite:trace3] [pid 16949] mod_rewrite.c(470): [client 10.1.1.1:62308] 10.1.1.1 - [email protected] [[email protected]/sid#55c3cba52388][rid#55c3cbbb3ed0/initial] [perdir /bag/] applying pattern '.*' to uri 'proxy:http://127.0.0.1:8080/bag/register/info?t=1579018407519', referer: https://[email protected]/bag/ [Tue Jan 14 17:13:28.338759 2020] [rewrite:trace4] [pid 16949] mod_rewrite.c(470): [client 10.1.1.1:62308] 10.1.1.1 - [email protected] [[email protected]/sid#55c3cba52388][rid#55c3cbbb3ed0/initial] [perdir /bag/] RewriteCond: input='keep-alive' pattern='upgrade' [NC] => not-matched, referer: https://[email protected]/bag/ [Tue Jan 14 17:13:28.338763 2020] [rewrite:trace1] [pid 16949] mod_rewrite.c(470): [client 10.1.1.1:62308] 10.1.1.1 - [email protected] [[email protected]/sid#55c3cba52388][rid#55c3cbbb3ed0/initial] [perdir /bag/] pass through proxy:http://127.0.0.1:8080/bag/register/info?t=1579018407519, referer: https://[email protected]/bag/ [Tue Jan 14 17:13:28.784337 2020] [rewrite:trace2] [pid 16949] mod_rewrite.c(470): [client 10.1.1.1:62308] 10.1.1.1 - - [[email protected]/sid#55c3cba52388][rid#55c3cbba0730/initial] init rewrite engine with requested uri /bag/status/latest, referer: https://[email protected]/bag/ [Tue Jan 14 17:13:28.784379 2020] [rewrite:trace1] [pid 16949] mod_rewrite.c(470): [client 10.1.1.1:62308] 10.1.1.1 - - [[email protected]/sid#55c3cba52388][rid#55c3cbba0730/initial] pass through /bag/status/latest, referer: https://[email protected]/bag/

[pjreed]

Sorry for this being open so long without comment, but I thought I'd let you know that I just release a major update, and I also included an example of using the Bag Database behind a reverse proxy in the documentation: https://swri-robotics.github.io/bag-database/installation/docker/behind-a-reverse-proxy

For what you're trying to do -- serve the Bag Database from a non-root path -- the easiest way to do that is to make the Tomcat server inside Bag DB's docker container also serve it from that path. There isn't a way to do that with the way the container is currently set up, but it would be very easy to build your own image that serves it from that path. If you edit the Dockerfile, you can change this line:

COPY --from=base-layer /src/target/*.war /usr/local/tomcat/webapps/ROOT.war

The name of the target war file determines the name of the path that is used to serve the application. ROOT.war is special and means that it will be served at /, but if you changed that to bag.war and build your own Docker image, that will cause it to be served from /bag, and then it should be easy to pass that through a reverse proxy without needing to remap any URLs.

[ptulpen]

Hello,
my work-around is currently to use the container direct and mv afterwards

podman run -d --name bagdb-frontend ...
podman exec bagdb-frontend /usr/local/tomcat/webapps/ROOT.war /usr/local/tomcat/webapps/bag.war
podman restart bagdb-frontend

This still leads to the errors I posted before, but we see no obvious errors so far
I want to update to bag3 the next days, lets see what happens there ;)