I am using nginx as a reverse proxy serving pihole at /pihole/ on port 80 and 443.
This currently does not work with PADD since
$ dig +short chaos txt domain.api.ftl @localhost
"http://pi.hole:8080/pihole/api"
The DiG command reurns port 8080 on which FTL is listening. This is not acessible, due to it binding to 127.0.0.1:8080. Additionally /pihole/ does not exist on the FTL webserver.
To avoid complicated logic to check what the reverse proxy is doing, my suggestion would be to let advanced users manually configure domain.api.ftl and local.api.ftl.
Did you try to use webserver.paths.prefix, introduced in v6.1?
Yes, I am using webserver.paths.prefix.
More information about my configuration and problem:
webserver.paths.prefix is set to /pihole
WEBSERVER.PORT is set to 127.0.0.1:8080
This means the actual port of the built in Webserver is not exposed.
Ngnix is listening on 80(redirect) and 443.
Ngnix is doing redirects from /admin to /pihole/admin and the same for /api via
location ~ ^/admin/(.*)$ { return 301 /pihole/admin/$1;
}
location ~ ^/api/(.*)$ { return 301 /pihole/api/$1;
}
The problem is that domain.api.ftl responds with the port of the built in webserver (8080, which is not exposed).
I want domain.api.ftl to be ”https://pi.hole:443/pihole/api” and not ”http://pi.hole:8080/pihole/api”.
This is mainly due to issues with PADD, which is searching for the api at the path given by domain.api.ftl.
Using PADD on localhost doesnt work either, since it uses local.api.ftl which responds with "http://127.0.0.1:8080/pihole/api/". On the built in webserver there is no /pihole("http://127.0.0.1:8080/api/" would be correct here).
webserver.paths.prefix is not used to change the path of the built in webserver, it just adjusts all the links.
So this is a PADD feature request, correct?
No, this is a FTL feature request, PADD not working is simply the result of the issue. The issue lies at domain.api.ftl.
My proposed solution is to make domain.api.ftl configureable to avoid complex logic checking for the reverse proxy