Is it possible to override a site level directive within a handle block?

1. The problem I’m having:

example.com {
	forward_auth *.*.*.*:9091 {
		uri /api/authz/forward-auth?authelia_url=https://exmaple.com/auth
	}
	reverse_proxy /auth* *.*.*.*:9091
	route /file* {
		forward_auth *.*.*.*:9091 {
			uri /api/authz/basic-auth
		}
		webdav {
			prefix /file
			root /etc/caddy/file
		}
	}
	handle /path1 {
	    reverse proxy 127.0.0.1:5050
	}
	handle /path2 {
	    reverse proxy 127.0.0.1:9090
	}
	handle /path3 {
	    reverse proxy 127.0.0.1:8080
	}
}

Basically, I would like for every other subpath to use:

	forward_auth *.*.*.*:9091 {
		uri /api/authz/forward-auth?authelia_url=https://exmaple.com/auth
	}

While only /file* uses:

		forward_auth *.*.*.*:9091 {
			uri /api/authz/basic-auth
		}

But without any success.

My question is, if there is subdirective inside and outside of a handle block, which one takes precedence?

2. Error messages and/or full log output:

No error, just not working.

3. Caddy version:

2.8.4

4. How I installed and ran Caddy:

docker

a. System environment:

Synology

Multiple handle blocks are mutually exclusive, meaning they allow a flow where only 1 of them is matched and executed. So, you can have something like this:

	handle /file* {
		forward_auth *.*.*.*:9091 {
			uri /api/authz/basic-auth
		}
	}
	handle {
		forward_auth *.*.*.*:9091 {
			uri /api/authz/forward-auth?authelia_url=https://exmaple.com/auth
		}
	}
1 Like

I’d suggest laying it out like this. You can nest handle to have them be mutually exclusive at different layers.

example.com {
	handle /auth* {
		reverse_proxy authelia:9091
	}

	handle /file* {
		forward_auth authelia:9091 {
			uri /api/authz/basic-auth
		}
		webdav {
			prefix /file
			root /etc/caddy/file
		}
	}

	handle {
		forward_auth authelia:9091 {
			uri /api/authz/forward-auth?authelia_url=https://exmaple.com/auth
		}

		handle /path1* {
			reverse proxy 127.0.0.1:5050
		}

		handle /path2* {
			reverse proxy 127.0.0.1:9090
		}

		handle /path3* {
			reverse proxy 127.0.0.1:8080
		}
	}
}
3 Likes

Thank you, the suggestion you provide makes a lot of sense!

Just out of curiosity, when I lay it like this, how does caddy decide who takes precedence?

example.com {
	forward_auth *.*.*.*:9091 {
		uri /api/authz/forward-auth?authelia_url=https://exmaple.com/auth
	}
	route /file* {
		forward_auth *.*.*.*:9091 {
			uri /api/authz/basic-auth
		}
	}

I was thinking that the first part matches / and second part matches /file* so second part should be prioritized, but it turns out not to be the case.

Caddy sorts directives according to this directive order. Scroll past that to see the explanation of how it works.

2 Likes

I actually read that, but I guess not carefully enough, and that’s on me.

Reading through it again, it seems that it my example, I should actually compare forward_auth and route, in which case forward_auth takes precedence. I think I can override it with order forward_auth after route, but then the part where forward_auth is not explicitly nominated would not have forward_auth.

So the example you provided is not only clearer but also the only way to go about it.

Please correct me if I’m wrong.

Using handle like I showed is certainly the most simple approach I think. You could get away with writing negated matchers for everything (cause there’s no else in Caddy, you’d have to basically duplicate the matchers but with not in front of them). That would be necessary to prevent your top-level forward_auth applying on requests further down in the config which might want to do a different forward_auth, etc.

But anyway, using handle blocks lets you write your config in a rough “if-elseif-elseif-else” kind of pattern (the last handle without a matcher being the else/fallback), and nested “if” within those as needed, etc.

2 Likes

Thank you for all the information! That’s more than enough and I will figure the rest out myself.

Caddy is such a powerful yet simple tool, I really love it!

1 Like

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