bag-database icon indicating copy to clipboard operation
bag-database copied to clipboard

bag-database behind a proxy

Open ptulpen opened this issue 5 years ago • 13 comments
trafficstars

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>

ptulpen avatar Jan 03 '20 16:01 ptulpen

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.

pjreed avatar Jan 03 '20 19:01 pjreed

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)

ptulpen avatar Jan 05 '20 20:01 ptulpen

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

pjreed avatar Jan 06 '20 14:01 pjreed

Yes, that makes a huge difference :)

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

ptulpen avatar Jan 07 '20 12:01 ptulpen

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/

pjreed avatar Jan 07 '20 15:01 pjreed

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 ?

ptulpen avatar Jan 08 '20 14:01 ptulpen

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.

pjreed avatar Jan 08 '20 15:01 pjreed

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

ptulpen avatar Jan 08 '20 21:01 ptulpen

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>

pjreed avatar Jan 08 '20 21:01 pjreed

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

ptulpen avatar Jan 09 '20 09:01 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/

ptulpen avatar Jan 15 '20 09:01 ptulpen

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.

pjreed avatar Sep 10 '20 22:09 pjreed

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 ;)

ptulpen avatar Sep 25 '20 09:09 ptulpen