Redirecting bug since 15.0.2

[mrzapp]

Whenever a redirect happens, like from the /apps/ to the /apps/files/ path, NextCloud now redirects using the server provided hostname and port instead of the one requested by the client.

For instance, if running via Docker on localhost:8000 and using a proxy pass with cloud.example.com, the address cloud.example.com/apps/ will redirect to localhost:8000/apps/files/.

This happens with the / to /login redirect as well, so this bug completely prevents access to the instance from the web interface, unless you manually correct the URL afterwards.

Also discussed here: https://help.nextcloud.com/t/nextcloud-15-redirect-to-local-ip/45352

[mrzapp]

Related to #13710

[RandomMetalhead]

Same problem and same setup:
Apache Proxy -> Docker -> Nexcloud and always redirecting to https://127.0.0.1:8080/login. With 15.0 it worked fine, update to 15.0.2 broke

[kesselb]

Does this help? https://docs.nextcloud.com/server/stable/admin_manual/configuration_server/reverse_proxy_configuration.html

If not please provide the information from the issue template (https://github.com/nextcloud/server/blob/master/.github/ISSUE_TEMPLATE/Bug_report.md).

[RandomMetalhead]

Provided links did not help.
What helped is changing:
'overwrite.cli.url' => 'https://XXXX.de',
to
'overwritehost' => 'XXXX.de', 'overwriteprotocol' => 'https',

It seems for me 'overwrite.cli.url' in config.php is broken

[mrzapp]

Yep, @RandomMetalhead's solution works

[kesselb]

Great 🎉

Provided links did not help.

I guess we could improve the documentation here. It's not obvious that the bold text are configuration parameters.

@RandomMetalhead you also need overwrite.cli.url (https://github.com/nextcloud/server/blob/stable15/config/config.sample.php#L477-L485)

[RandomMetalhead]

The main issue was, that in 15.0.0 only having 'overwrite.cli.url' and 'overwriteprotocol' was sufficient for Nextcloud. It seems, that for 15.0.2 'overwritehost' is necessary. At least in docker version with Apache-Proxy. I have readded 'overwrite.cli.url', too. So my config looks like this now and is working perfectly:

'overwritehost' => 'XXX.de', 'overwriteprotocol' => 'https', 'overwrite.cli.url' => 'https://XXX.de',

[kesselb]

The main issue was, that in 15.0.0 only having 'overwrite.cli.url' and 'overwriteprotocol' was sufficient for Nextcloud. It seems, that for 15.0.2 'overwritehost' is necessary.

Thank you for pointing this out 👍

@MorrisJobke @rullzer @J0WI they were many reports within the last days about this. I suppose this is related to #13116 because the docker network is not trusted by default. In this case HTTP_FORWARDED_HOST is not longer trusted. What do you suggest? Is it possible to add this for the official docker image? 🏓

[kesselb]

CIDR is possible for trusted_network since nextcloud 15. Something like 172.0.0.0/8 as trusted proxy would work (not sure if docker uses 172.x all the time).

@kyrofa @enoch85 (not sure if snap or vm is running into the same. just in case)

[enoch85]

Thanks for the heads up @danielkesselberg Nothing reported, and nothing I've experienced myself.

[J0WI]

See also nextcloud/docker#527

[kesselb]

nextcloud/docker#527 makes it easier to configure these parameters 👍

• Nextcloud 15.0.0: Nextcloud accept HTTP_FORWARDED_HOST from Nginx (or any other proxy).
• Nextcloud 15.0.2: Nextcloud does not accept HTTP_FORWARDED_HOST from Nginx (or any other proxy).

In #13116 we did some security hardening (trust HTTP_FORWARDED_HOST only if proxy is trusted proxy). Nextcloud behind nginx worked well for most people without setting overwritehost. @J0WI do you think we could set trusted_network to 172.0.0.0/8 by default (and make it configurable) for the docker image?

[J0WI]

172.0.0.0/8 would be a bad idea, only 172.16.0.0/12 is private. If we trust them by default, we should probably trust all RFC 1918 (and RFC 4193?) networks?
However, you can use any other IP for Docker, so I think we need nextcloud/docker#527 anyway.

[neeral85]

I'm running https://www.hanssonit.se/nextcloud-vm/

my ip is 172.18.1.10 and
'overwritehost' => 'XXX.de', 'overwriteprotocol' => 'https', 'overwrite.cli.url' => 'https://XXX.de',
was not working for me.