In Caddy v1 youāll need to rely on rewrite hacks in order to achieve this. Whitelist is slightly more complicated than blacklist, but theyāre both doable. See examples with comments:
# Proxy from whitelist
example.com {
# Prepend with special prefix to proxy from
rewrite {
if {path} starts_with /foo
if {path} starts_with /allowed
if {path} starts_with /path
to /proxywhitelist{uri}
}
# Stop malicious actors from abusing your proxy prefix
# to get non-whitelisted requests past the whitelist
# - this works because only one rewrite goes off, either
# the proxy prefix or this security measure. Nobody should
# ever be requesting your proxy prefix directly.
rewrite /proxywhitelist {
to /forbidden
}
status 403 /forbidden
# Proxy and strip prefix to make this process transparent
proxy /proxywhitelist 127.0.0.1 {
without /proxywhitelist
}
}
# Proxy except for blacklist
example.com {
# We use status here to blacklist paths directly with 403
# responses, but you can also use a bulk rewrite to handle
# the blacklist with another directive if you need to,
# just adapt the other example into a blacklist
status 403 {
/bar
/blacklisted
/denied
}
# Proxy everything else
proxy / 127.0.0.1
}
In v2, this is ludicrously easier with matchers. Itās hard to state just how much better this kind of scenario is is handled in v2.
# Proxy non blacklisted
example.com {
@notblacklisted {
not {
path /bar* /blacklisted* /denied*
}
}
reverse_proxy @notblacklisted 127.0.0.1
}
Alternately to proxying the non-blacklisted paths and leaving blacklisted responses ambiguous (probably 404s), you could remove the not and instead handle it as a blacklist by responding with a 403 (or other response as desired), then reverse proxying everything else.
Nice! Thank you! Thereās no way I would have figured out the V1 all by myself.
V2 will be a definite choice as soon as the beta label is gone.
(Yes, I know itās production ready, but I just canāt bring myself to installing security software on clientsā servers with a ābetaā suffix.)
Greatly appreciated that you provided solutions for both versions.
ā
Just a side question about how the wildcard is matching urls.
I have a āfolderā prefix in the URL which might be blank, or a folder.
If I wanted to match:
/bar
/prefix1/bar
/prefix2/bar
Would /*/bar suffice? Or would that fail on /bar?
Any differences between V1 and V2 on wildcards?
Even with v2, Iād also be wary of /*/bar. Itās not limited by element - itās a globular match, so it would hit /prefix1/bar, /prefix2/bar, but also /some/really/long/path/bar.
(Note also that as a globular match, /foo* will be satisfied by /foo/bar but also /foobar - take note of that if matching a specific path element is important! /foo/* might be better in some cases.)
You can use a path_regexp matcher in v2 for those ones in order to be safe when dealing with strict path elements.