Open Andreas02-dev opened 1 month ago
There's an open issue, nextcloud/server#7005, about the same issue. Not sure if the docker image should implement a workaround or just try to get upstream support for hostnames in the trusted_proxies config option. I was experimenting with some Nextcloud docker configuration setup which implements the naive fix (link), but given the issues mentioned in the nextcloud/server issue I'm not using it on my live server just yet.
When manually editing config.php, the result of php occ config:system:get trusted_proxies will be the IP of the proxy as the gethostbyname function will get evaluated correctly.
Have you tried using an auto config hook script to set it entirely via occ config:system:set
?
https://github.com/nextcloud/docker#auto-configuration-via-hook-folders
The point of the the hook script support is to permit any occ
command - and thus any Nextcloud configuration directive - to be set in an automated fashion regardless of environment variable support.
In majority of cases you can simply add the docker subnet range (172.16.0.0/12) - this will cover all reverse proxies running on the same host. The most "open" approach is to add all private non-routable IP ranges
TRUSTED_PROXIES=172.16.0.0/12 192.168.0.0/16 10.0.0.0/8 fc00::/7 fe80::/10 2001:db8::/32
this will accept all reverse proxies from internal network but still reject headers from public IPs.
Definitely little less secure than exact assignment should be good for most installations.
When manually editing config.php, the result of php occ config:system:get trusted_proxies will be the IP of the proxy as the gethostbyname function will get evaluated correctly.
Have you tried using an auto config hook script to set it entirely via
occ config:system:set
?https://github.com/nextcloud/docker#auto-configuration-via-hook-folders
The point of the the hook script support is to permit any
occ
command - and thus any Nextcloud configuration directive - to be set in an automated fashion regardless of environment variable support.
Thanks for the advice. I've currently migrated away from the Docker installation, but I might migrate back and test this when I have some more time this summer, due to an issue with OnlyOffice & Nextcloud not being able to save a file in a bare-metal installation.
Would it be best to keep this open for now?
I would leave this open since the solution above is more of a bandaid fix to make the warning disappear. An alternative to that would simply be to give the reverse proxy a fixed IP in docker and just add the IP. But none of these solutions are completely portable as just gethostbyname('') working.
When setting the
TRUSTED_PROXIES
environment variable as shown in https://github.com/nextcloud/server/pull/44495#issuecomment-2079798695(TRUSTED_PROXIES=gethostbyname('nginx-proxy')
, I get the warningYour "trusted_proxies" setting is not correctly set, it should be an array of IP addresses - optionally with range in CIDR notation.
and when executingphp occ config:system:get trusted_proxies
, the result isgethostbyname('proxy')
. When manually editingconfig.php
, the result ofphp occ config:system:get trusted_proxies
will be the IP of the proxy as thegethostbyname
function will get evaluated correctly.Since it's best practice to not assign static IP's in a compose file, being able to evaluate
gethostbyname
when using the TRUSTED_PROXIES environment variable is quite important especially for the Nextcloud Docker image.As @xeluior mentioned in this comment, we might be able to naively apply
gethostbyname
to all trusted proxies when the container starts, however container restarts would likely break this, and I'm not sure if Nextcloud's config works across container restarts withgethostbyname
either.Furthermore, it might be good to also discuss if we want to only evaluate
gethostbyname
or if we should evaluate the exact same way as config.php does for consistency.