"Classic" subfolder issues? (I read the wiki)

Help
1

1. Caddy version (caddy version):

2.3.0

2. How I run Caddy:

Caddy-docker-proxy

a. System environment:

Caddy-docker-proxy via docker-compose on host Ubuntu Budgie 20.10.

b. Command:

Not aware. caddy-docker-proxy takes care of everything.

c. Service/unit/compose file:

services:
  firefox:
    (...)
    labels:
      caddy_1: $DOMAIN
      caddy_1.handle_path: /firefoxsync*
      caddy_1.handle_path.reverse_proxy: "{{upstreams 5000}}"
      caddy_1.tls: $EMAIL
  bitwarden:
    (...)
    labels:
      caddy_2: $DOMAIN
      caddy_2.handle_path: /bitwarden*
      caddy_2.handle_path.reverse_proxy: "{{upstreams 80}}"
     # caddy2.handle_path.reverse_proxy_2: "/notifications/hub/negotiate {{upstreams 80}}"
     # caddy2.handle_path.reverse_proxy_3: "/notifications/hub {{upstreams 3012}}"
      caddy_2.tls: $EMAIL
      caddy_2.encode: gzip
      caddy_2.header.X-XSS-Protection: '"1; mode=block;"'
      caddy_2.header.X-Frame-Options: "DENY"
      caddy_2.header.X-Content-Type-Options: "none"
  syncthing:
    (...)
    labels:
      caddy_3: $DOMAIN
      caddy_3.handle_path: /syncthing*
      caddy_3.handle_path.reverse_proxy: "{{upstreams 8384}}"
      caddy_3.tls: $EMAIL
  onlyoffice:
    (...)
    labels:
      caddy_5: $DOMAIN
      caddy_5.handle_path: /office*
      caddy_5.handle_path.reverse_proxy: "{{upstreams 80}}"
      caddy_5.tls: $EMAIL
      caddy_5.file_server: ""
      caddy_5.encode: gzip
      caddy_5.header.X-Content-Type-Options: "nosniff"

d. My complete Caddyfile or JSON config:

mydomain.tld {
        handle_path /bitwarden* {
                encode gzip
                header {
                        X-Content-Type-Options none
                        X-Frame-Options DENY
                        X-XSS-Protection "1; mode=block;"
                }
                reverse_proxy 172.26.0.3:80
        }
        handle_path /firefoxsync* {
                reverse_proxy 172.26.0.4:5000
        }
        handle_path /office* {
                encode gzip
                file_server
                header {
                        X-Content-Type-Options nosniff
                }
                reverse_proxy 172.26.0.6:80
        }
        handle_path /syncthing* {
                reverse_proxy 172.26.0.5:8384
        }
        tls mydomain@mydomain.tld
}

3. The problem I’m having:

I am trying to switch from subdomains to subfolders to access my services. I have 2 problems:

  1. Even with syncthing* a slash at the end syncthing/ is still required to load the page properly otherwise it looks like a text-only site. This is not the case for bitwarden, it works without slash at the end.
  2. The admin page of bitwarden (normally accessible via subdomain.domain.com/admin) at mydomain.tld/bitwarden/admin is text-only even with a slash at the end.
  3. Onlyoffice normally redirects to subdomain.domain.com/welcome now with this subfolder config it does the same! so nothing loads. It does work when I manually go to domain.tld/office/welcome

4. Error messages and/or full log output:

no errors.

5. What I already tried:

Lot’s of things as the dev of caddy-docker-proxy really helped me get it working up until this point.
Since I am so close now, I am reluctant to switch back to subdomains.
I have started to believe subfolders are more secure by obscurity: subdomains are publicly known, by DNS servers etc. By using subfolders, someone needs to know the subfolder name to access it.

6. Links to relevant resources:

The "subfolder problem", OR, "why can't I reverse proxy my app into a subfolder?"

Unfortunately, it is like a blog article, it does not really explain how to do it, with examples etc.

2

You’ve been helped here:

3

Yes that’s in my post above:

Also, remaining issues: see point 3 above. I can’t keep asking him for things that are missing in wiki or documentation right?
The wiki article I linked really reads as if a big part is missing. It explains the situation and bam stops.

I opened this topic as he helped me get this close, I have been doing more trial and error but just don’t see how to solve those last remaining issues.

4

The answer is there’s no good answer. I can’t realistically recommend going down that path. It’ll just be headaches forever. You’ll be playing whack-a-mole digging through every kind of response those apps can serve. Using subdomains is the only option that will always work without extra effort.

1 Like
5

Thanks, maybe I needed to hear that. I’ve been blindly focused on getting this working while I had a perfectly good working setup with subdomains. I’ll switch back to that.

1 Like
6

Thanks to @francislavoie for laying that out. So, yeah, you do have a good point about it explaining what the filtering/header rewriting method is and then kinda immediately stopping. As the author of that wiki entry I’d just like to throw in some of my thoughts on this and why I did that.

Unfortunately that part is pretty complex and incredibly dependent on what you’re actually dealing with. It needs to be configured on a per-app basis. There is no actual configuration I could list by way of example that will properly handle more than one individual backend since it must be tailored this way. You need to do this tailoring process for each backend that has no URL base option.

I could possibly elaborate further and outline the process you’d need, the things you need to investigate, and how to piece that into a working config, but that part would be easily four times as long as the rest of the document as it currently stands.

And it’s very much a hack - suboptimal in many ways, prone to breakage if the upstream app ever updates and changes the way it handles links even in a minor way… In a sense, if you’ve got the capability to research for yourself and sort out how to do the things I explained can be done, then you’ve met the level of expertise I’d recommend you having in order to achieve (and maintain) that configuration. Otherwise I feel like it’s just generally not worth it.

3 Likes
7

This topic was automatically closed after 30 days. New replies are no longer allowed.